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(54) System and method for providing mobile data service 



(57) Location registration Information transmitted 
from a mobile node is notified to a home agent via a 
foreign agent, an AAAF, and an AAAH. Upon receipt of 
the location registration infomiation, the AAAH extracts 
the service profile corresponding to the mobile node 
from a service control database, and edits the extracted 



profile Into a format that Is not dependent on a service 
type. The AAAH then distributes the edited service pro- 
file to the home agent and the foreign agent. The home 
agent and theforeign agent provide the service request- 
ed by the mobile node according to the distributed serv- 
ice profile. 
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Description 

Baclcground of tlie Invention 
Field of the Invention 

[0001] The present invention relates to a system and 
a method distributing service information in a network, 
and more particularly, to a system and a method distrib- 
uting to network devices information about a sen^ice 
provided by a network in the network that accommo- 
dates mobile nodes. 

Description of the Related Art 

[0002] With the rapid expansion of the Internet, the 
volume of IP packet traffic has been sharply increasing. 
Also, with the popularization of cellular phones, stand- 
ardization has been advancing by IMT-2000 (Interna- 
tional Mobile Telecommunications 2000), and high- 
speed IP communications are expected to become 
widespread under a mobile environment However, it 
cannot be said that the techniques for enhancing the 
functions of IP communications (for example, QoS 
(Quality of Service) , a value-added service such as a 
network-wide load distribution of a WWW server, etc.) 
have not fully matured although they are likely to be in 
great demand. 

[0003] As one method controlling an IP network, PBN 
(Policy-Based Networking) is proposed mainly by U.S. 
vendors. 

[0004] With the PBN, an operation policy is set in a 
network device arranged on a network, and each net- 
work device operates in compliance with the policy, 
whereby diversified value-added services are provided. 
Examples of the value-added services include guaran- 
tee of a bandwidth, guarantee of a delay time, packet 
filtering, access restriction, etc. To provide these serv- 
ices, RSVP (Resource Reservation Protocol), Diff-Serv 
(Differentiated Services), etc. are frequently used. The 
Diff-Serv is a protocol for preferentially transferring a 
particular packet based on the priority assigned to each 
packet. 

[0005] However, since a mobile environment is not 
fully considered in the norma! PBN, the following prob- 
lems occur. Namely, if a policy (the above described 
QoS, etc.) is set for each mobile terminal in the PBN, 
the corresponding policy must be set for all of network 
devices that can possibly accommodate the mobile ter- 
minal. As a result, the amount of setting the policy in the 
entire network increases. Additionally, because the 
number of network devices that can possibly accommo- 
date the mobile temriinal is very large, it is impractical to 
set the policy for each mobile terminal in each of the 
devices. Furthemiore, If information notified in the PBN 
is applied individually to corresponding fundamental 
service such as a mobile IP, etc., It is necessary to pre- 
pare and review a specification for each service. 
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[0006] As a protocol for accommodating a mobile ter- 
minal in a network device, IP Mobility Support (herein- 
after referred to as a "mobile IP" or "MIR") is issued by 
RFC 2002. 

5 [0007] In an IP network where voice and data com- 
munications are integrated and terminals of various 
types are connected, it is essential to implement the 
QoS function for the purpose of protecting delay-sensi- 
tive traffic or traffic with high business priority. As a meth- 

10 od Implementing the QoS function, int-Serv, Diff-Serv, 
etc. are proposed. The Diff-Serv with a^small overhead 
is considered to be promising for a carrier or a backbone 
network among the proposed methods. 
[0008] However, with the Diff-serv, policies must be 

15 set for all of network devices on a path. Therefore, net- 
work management Is complicated only with the Diff- 
Serv. As a result, a concept is proposed such that a pol- 
icy server Is arranged on a network, and the policy serv- 
er sets policies for respective devices, whereby the en- 

20 tire network Is managed in a centralized manner (this 
concept is sometimes referred to as the PBN). 
[0009] However, in a seamless global network config- 
ured by various providers and carriers that accommo- 
date mobile terminals, it is necessary to allow all of local 

25 networks to detennlne a policy for a possibly connected 
user and to set infomnation for network devices. If at- 
tempts are made to implement this with the PBN, each 
of the local networks must store the policy information 
of all of users, or policy information must be set before- 

30 hand for all of the network devices to which a user can 
possibly be connected. However, since the number of 
users is very large, it is extremely inefficient and imprac- 
tical to use this method. 

[0010] Furthermore, if each network device is made 

35 to continuously hold the policy information of all of users, 
the memory amount of a network device must be in- 
creased, leading to a deterioration of the throughput, in 
contrast, if a method inquiring a policy server on demand 
without making each network device hold policy infor- 

40 mation Is adopted, the overhead of an inquiry becomes 
large, leading to a greater possibility that SI_A (Service 
Level Agreement) cannot be complied. 
[0011] To overcome the above described problems, 
the applicant of the present invention previously pro- 

45 posed the method distributing the Information about a 
value-added service to network devices by using a pro- 
tocol which is similar and relevant to the mobile IP. A 
patent application disclosing this method was filed (Pat- 
ent Application Numbers in Japan are 11-276703 and 

50 2000-1 01 41 4, and Application Number in United States 
Is 09/672,866). Hereinafter, the mobile IP and the meth- 
od proposed in that patent application will be briefly de- 
scribed. 

[0012] Fig, 1 is a schematic diagram for explaining the 
55 mobile IP and the previously filed invention. An AAAH 
(Authentication, Authorization and Accounting Home) 1 
and an AAAF (Authentication, Authorization and Ac- 
counting Foreign) 2 authentbate a mobile node (MN) 
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11, determine whether or not to authorize an access to/ 
from the mobile node 11, and perform an accounting 
process for the mobile node 11 . A service control data- 
base 3 stores the information (service control informa- 
tion) about a service provided to each mobile node 11 . 
[0013] An l-IA (Home Agent) 4 and an FA (Foreign 
Agent) 5 are routers which accommodate the mobile 
node 11, and relay IP packets according to the service 
control information distributed from the AAAH 1 or the 
AAAF 2. 

[0014] This network comprises: (1) the function for de- 
tecting the location of a mobile node 1 1 ; (2) the function 
for registering the location of the mobile node 11; and 
(3) the function for transferring packets to the mobile 
node 11 at a location where the mobile node visits. 
[001 5] Each FA periodically broadcasts an advertise- 
ment message. The IP address of the con-esponding FA 
is included in the advertisement message. Accordingly, 
if the mobile node 11 moves from the communication 
area of one FAtothatof another, the IP address included 
in the advertisement message received by the mobile 
node 11 wifl change at a certain tirrie point. When the 
change in the iP address in the advertisement message 
is detected, the mobile node 11 Is recognized to enter 
the communication area of a different FA, and the IP ad- 
dress of the mobile node 1 1 is notified to the new FA and 
HA 4/ At this time, the new FA notifies its IP address to 
the HA4. In this way, the new FA that newly accommo- 
dates the mobile node 1 1 is registered to the HA 4, and 
the IP address of the mobile node 1 1 is registered to the 
new FA. 

[0016] A packet transfer from a CN (Correspondent 
Node) 12 to the mobile node 11 is made as follows. 
Namely; the packet to which the IP address of the mobile 
node 11 is assigned as a destination address is once 
transferred to the HA 4. Upon receipt of the packet ad- 
dressed to the mobile node 11 , the HA 4 transfers this 
packet to the FA that currently accommodates the mo- 
bile node 11. Here, the FA 5 is assumed to accommo- 
date the mobile node 11 . In this case, the FA 5 receives 
the packet from the HA 4, and transrriits the packet to 
the mobile node 11 . In this way, the packet is transferred 
to the node at a location where the mobile node visits. 
[0017] With the above described method, sen/ice 
control Infonnatlon for each mobile node is distributed 
to the FA which accommodates the mobile node 11 ac- 
cording to the location registration. For example, if the 
mobile node 11 enters the communication area of the 
FA 5, the AAAH 1 extracts the sen/Ice control Informa- 
tion of the mobile node 11 from the service control da- 
tabases, and distributes the extracted infomnation to the 
HA 4 and the FA 5. The HA 4 and the FA 5 then execute 
the value-added sen^ice (QoS, packet filtering, and so 
on) requested by the mobile node 11 according to the 
service control infonmatlon. 

[0018] In this way, a service equivalent to the existing 
PBN can be provided under the mobile environment. At 
this time, the sen/ice control Information (corresponding 
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to a PBN policy) is distributed not to all of FAs, but only 
to the FA which actually accommodates the mobile node 
11. 

[0019] However, this method still has the followfrjg 
5 problems. 

(1) Since service control infomnation is configured 
in a fonmat that differs depending on each service, 
an HA and an FA must be conscious of a service. 

10 (2) Service control information is generated for all 
of mobile terminals, and distributed to an HA and 
an FA regardless of whether or not a contract to re- 
ceive a value-added sen/ice is made. As a result, 
an overhead becomes large. 

IS (3) The function for replacing the processes specific 
to the mobile IP with the processes corresponding 
to the functions inherent In a router is required. Ac- 
coniiingly, if the functions of the mobile IP are ex- 
panded, the programs of an HA and an FA must be 

20 modified in some cases. Consequently, tliere is a 
possibility that a service control method itself must 
be changed. 

(4) In a system where a single virtual address is as- 
signed to a plurality of hardware resources, syn- 
25 chronizatlon between an HA and an FA is not es- 
tablished for the procedure for selecting one of the 
plurality of hardware resources when a packet Is 
transferred to the virtual address. 

30 Summary of the Invention 

[0020] The present Invention aims at providing a 
method defining a val ue-added service for each terminal 
in an IP network including a mobile environment, and 
35 allowing a value-added service to be added and extend- 
ed with greater scalability. 

[0021] A mobile communications service providing 
system according to the present invention assumes the 
configuration where the location registration request in- 

40 formation transmitted from a mobile node is notified to 
a home agent via a foreign agent and a server system, 
and the information in reply to the location registration 
request Information is returned from the home agent to 
the mobile node via the server system and the foreign 

45 agent, whereby the location of the mobile node is reg- 
istered to the home agent and the foreign agent, and a 
mobile communteations service is provided based on 
the registration. The home agent and the foreign agent 
comprise a controlling unit for determining the transfer 

so destination of a packet. The server system comprises: 
an extracting unit extracting a service profile corre- 
sponding to the mobile node from the database for man- 
aging service profiles including the information for pro- 
viding a service requested by a mobile node; a service 

55 managing unit editing the service profile extracted by the 
extracting unit into the format which is available to the 
controlling unit; and a distributing unit distributing the 
service profile edited by the service managing unit to the 
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home agent and the foreign agent. The home agent and 
the foreign agent utilize the controlling unit according to 
the service profile distributed by the server system, 
whereby a service is provided. 

[0022] According to the present Invention, a service s 
profile is edited by a server system into the fomnat that 
is available to a home agent and a foreign agent un- 
changed. As a result, the home agent and the foreign 
agent do not need to be conscious of the type of a serv- 
ice when providing a requested service to each mobile io 
node. As a result, modifications are reduced in the pro- 
grams or the data used by the home agent and the for- 
eign agent when a service is added/changed. 
[0023] Note that the server system niay not distribute 
a service prof lie to the home agent and the foreign agent is 
If the mobile node does not request a value-added serv- 
ice In the above described configuration. At this time, 
the home agent and the foreign agent may respectively 
provide a fundamental service according to the informa- 
tion that the home and the foreign agents themselves 
generate. 

[0024] In this configuration, the amounts of Informa- 
tion exchanged between the server system, and the 
home and the foreign agent decrease. Additionally, the 
memory space for storing a service profile can be re- 25 
duced in each home agent and foreign agent, which 
contributes to an improvement in the processing speed, 
[0025] Additionally, in the above described configura- 
tion, it may be assumed that an address range available 
to a predetemriined service is specified beforehand, a so 
service profile including the information representing the 
address range specified beforehand as a condition for 
extracting a particular packet from among received 
packets may be preset In the home agent and the for- 
eign agent, and the server system may assign an ad- 35 
dress within the address range specified beforehand to 
the mobile node which requests the predetermined 
service. 

[0026] In this configuration, the packet transmitted to/ 
from the mobile node Is extracted by the home iagent or 40 
the foreign agent according to the service profile, and 
the service (namely, the above described predeter- 
mined service) corresponding to the service profile is ex- 
ecuted. Accordingly, also in this configuration, the 
amounts of information exchanged between the server 
system, and the home agent and the foreign agent de- 
crease. Furthermore, the memory space for storing a 
service profile can be reduced in each home agent and 
foreign agent, which contributes to an improvement In 
the processing speedt so 
[0027] Furtherrnore, in the above described configu- 
ration, when providing a service fortransferring a packet 
having a single virtual address as a destination address 
which is assigned to a plurality of mobile nodes to an 
arbitrary one of the plurality of mobile nodes, an address ss 
proxy server which receives the packet assigned the 
above described virtual address maybe arranged, and 
the server system may distribute to the address proxy 



server the service profile for extracting the packet as- 
signed the virtual address and for transferring the packet 
to a particular mobile node among the plurality of mobile 
nodes, and may also distribute to a foreign agent the 
service profile for transferring the packet addressed to 
the foreign agent which accommodates the particular 
mobile node to the particular mobile node. 
[0028] In this configuration, the transfer of the packet 
assigned the virtual address is controlled by the server 
system in a unified manner. Accordingly, the packet hav- 
ing the virtual address as a destination Is securely trans- 
ferred to the particular node detemrilned by the server 
system. 

Brief Description of the Drawings 
[0029] 

Fig. 1 is a schematic diagram for explaining a mo- 
bile IP and the previously filed invention; 
Fig. 2 is a schematic diagram explaining the back- 
ground of the present invention; 
Fig. 3 Is a schematic diagram showing the network 
configuration of a embodiment according to the 
present invention; 

Fig. 4 is a block diagram showing the functions of 
the embodiment according to the present invention; 
Fig. 5 is a block diagram showing the functions of 
an AAAH; 

Fig. 6 exemplifies the originai data of service pro- 
files stored in a service control database; 
Fig. 7 exemplifies the sen^ice qualities registered to 
the service control database; 
Fig. 8 exemplifies accounting methods registered 
to the service control database; 
Fig. 9 exemplifies a restrictbn condition registered 
to the servbe control database; 
Fig. 1 0 exemplifies the profile for a DIfF-Serv serv- 
ice; 

Fig. 11 exemplifies the profile for an ANYCAST 
service; 

Fig. 12 exemplifies the service profile generated by 
an AAAH; 

Fig. 13 exemplifies an ANYCAST address manage- 
ment table; 

Fig. 14 exemplifies the session transaction of the 
AAAH; 

Fig. 1 5 Is a block diagram showing the function of 
an AAAF; 

Fig. 1 6 exemplifies the session transaction of the 
AAAF; 

Fig. 1 7 is a block diagram showing the functions of 
an HA, an FA, and a CN; 

Fig, 1 8 exemplifies the session transaction of the 
HA and the FA; 

Fig, 1 9 exemplifies a service profile cache; 
Fig. 20 exemplifies a search policy management ta- 
ble; 
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Fig. 21 exemplifies a visitor list; 

Fig. 22 exemplifies mobility binding; 

Fig. 23 exemplifies a binding cache; 

Fig. 24 exemplifies an ANYCAST table; 

Fig. 25 exemplifies a routing table; 5 

Fig. 26 shows the sequence for distributing service 

profiles (No. 1); 

Fig. 27 shows an initial state; 

Figs. 28A and 28B exemplify the service profiles 

generated by the FA at the time of an Initial config- 

uration; 

Fig. 29 exemplifies the service profile generated by 
the HA at the time of an initial configuration; 
Fig. 30 shows the procedure for generjating a serv- 
ice profile by the AAAH; 

Figs. 31 A and 31 B exemplify the service profiles to 
be distributed to the HA; 

Figs. 32A and 328 exemplify the service profiles to 
be distributed to the FA; 

Fig. 33 shows the procedure for setting service pro- 
files in the HA; 

Fig. 34 shows the procedure for transferring service 
profiles to the AAAF; 

Fig. 35 shows the procedure for setting service pro- 
files in the FA; 

Fig, 36 shows the procedure for transferring a pack- 
et from a mobile node to a correspondent node; 
. Fig. 37 shows the procedure for transferring a pack- 
et from the correspondent node to the mobile node; 
Fig. 38 shows the sequence for distributing sen^ice 30 
profiles (No. 2); 

Fig 39 shows the sequence for distributing service 
profiles (No. 3); 

FigMO shows the sequence for distributing service 
profiles (No. 4); 

Fig. 41 shows the sequence for distributing service 
profiles (No. 5); 

Fig. 42 is a flowchart explaining the operations of 
the AAAH; 

Fig. 43 Is a flowchart explaining the operations of 
the AAAF (No. 1); 

Fig. 44 is a flowchart explaining the operations of 
the AAAF (No. 2); 

Fig. 45 is a flowchart explaining the operations of 
the HA, the FA. and the CN ; 
Fig. 46 exeriiplif les the service profile set In the HA; 
Fig. 47 exemplifies the service profile set in the FA; 
Fig. 48 shows an example of a method predeter- 
mining an IP address range used for service class- 
es; 

Fig. 49 exemplifies the sequence for setting a serv- 
ice profile in a route optimization procedure; 
Fig. 50 is a schematic diagram explaining an ANY- 
CAST service; 

Fig. 51 exemplifies a service profile distributed to S5 
an address proxy server; 

Fig. 52 exemplifies a service profile distributed to 
the HA; 



Fig. 53 exemplifies a service profile distributed to 
the FA (No. 1); 

Fig. 54 exemplifies a service profile generated by 
the FA; 

Fig. 55 exemplifies a service profile distributed to 
the FA (No. 2); 

Fig. 56 shows the sequence for setting ANYCAST 
information (No. 1); 

Fig. 57 shows the sequence for setting the ANY- 
CAST information (No. 2); 

Fig. 58 shows the sequence for transferring a pack- 
et with an ANYCAST service; 
Fig. 59 shows the sequence for canceling the reg- 
istration to the ANYCAST service (No. 1); 
Fig. 60 shows the sequence for canceling a regis- 
tration to the ANYCAST service (No. 2); 
Fig. 61 shows the format of the mobile IP; 
Fig. 62 A shows the format of an IP header; 
Fig, 628 shows the format of a UDP header; 
Figs. 63A through 63D show the format of a mobile 
IP registration request message; 
Figs. 64A and 648 show the fonnat of a mobile IP 
registration reply message; 

Fig. 65 shows the fonnat of a mobile IP BU mes- 
sage; 

Fig. 66 shows the format of a mobile IP BA mes- 
sage; 

Fig. 67 shows the format of a DIAMETER message; 
Fig. 68 shows the format of the common header of 
the DIAMETER message; 

Figs. 69A through 69C show the fonnat of AVP of 
the DIAMETER message; 

Fig. 70 shows the fonnat of an AMR message of a 
DIAMETER protocol; 

Fig. 71 shows the fonnat of an MAR message of the 
DIAMETER protocol; 

Fig. 72 shows the format of an AMA message of the 
DIAMETER protocol; and 

Fig. 73 shows the fonnat of an HAA message of the 
DIAMETER protocol. 

Description of the Preferred Embodiments 

[0030] Hereinafter, embodiments according to the 
present invention will be described In the following order 
by referring to the drawings. 

1 . 8ackground of the present invention 

2. Outiine of the present invention 

3. Configuration of an entire system 

4. Configuration of an AAAH 

5. Configuration of an AAAF 

6. Configurations of an HA, an FA, and a CN 

7. Sequence for distributing service profiles 

7A. In the case where the AAAH specifies the 
HA 

78. In the case where the AAAF specifies the 
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HA 

7C. Flowchart of each entity 
7D. Management of service profiles 
7E. Route optimization 

8. ANYCAST service 

[0031] Note that entire description of Japanese Pat- 
ent Application No.2000-043408 is incorporated by ref- 
erence. 

1 . Bacl<ground of the present invention 

[0032] First of all, the background of the present in- 
vention is described by referring to Rg. 2. Provided here 

Is the case where a mobile node accommodated by a 
home agent moves to the communication area of a for- 
eign agent. 

[0033] Procedural step 1 : A home agent (HA) 200 and 
a foreign agent (FA) 500 periodically Issue an agent ad- 
vertisement message in which the IP address of either 
of the agents itself is set. Amobile nodie 600 determines 
whether the mobile node 600 itself stays In either the 
communication area of the home agent 200 or that of 
the foreign agent 500 by receiving an agent advertise- 
ment message. It is assumed that the mobile node 600 
currently visits the communication area of the home 
agent 200. 

[0034] Procedural step 2: When the mobile node 600 
moves from the communication area of the home agent 
200 to that of the foreign agent 500, it receives an agent 
advertisement message from the foreign agent 500, Up- 
on receipt of this message, the mobile node 600 issues 
a location registration request message to the foreign 
agent 500. The information for Identifying the mobile 
node 600 is set in this message. 

[0035] Procedural step 3: Upon receipt of the location 
registration request message from the mobile node 600, 
the foreign agent 500 transmits an AMR (authentication 
request) message to an AAAF (Authentication, Author- 
ization and Accounting Foreign) 400 via an IP network 
80 so that authentication, authorization, accounting, etc. 
are performed. The information for identifying the mobile 
node 600 and the foreign agent 600 are set in this mes- 
sage. 

[0036] Procedural step 4: The AAAF 400 identifies an 
AAAH (Authentication, Authorization and Accounting 
Home) 100, which performs the authentication of the 
mobile node 600, by analyzing the received message, 
and forwards the AMR message to the AAAH 100 via 
the IP network 80. 

[0037] Procedural step 5: The AAAH 100 extracts 
necessary information from the received AMR mes- 
sage, and performs the authentication of the mobile 
node 600. The AAAH 100 extracts, for example, a mo- 
bile node identifier (NAI: Network Access Identifier) from 
the AMR message, and accesses a service controi da- 
tabase 300 by using the extracted Identifier as a key. As 
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a result, a user profile (service profile information) cor- 
responding to the mobile node 600 is extracted. If the 
AAAH 1 00 successfully performs the authentication of 
the AMF( message, It adds the above described service 
5 profile infomiatlon to an HAR (registration request) mes- . 
sage, and forwards the message to the home agent 200 
via the IP network 80. 

[0038] Procedural step 6: The home agent 200 ex- 
tracts information such as a session ID, lifetime, etc. 

10 from the received HAR message, and perfonns a loca- 
tion registration of the mobile node 600. Namely, the 
home agent 200 extracts from the HAR message the 
Information for fonwarding a packet addressed to the 
mobile node 600 to a location where the mobile node 

15 600 visits, and generates service control Information (a 
serviceprofile table of a service control transaction 230). 
The resultant information Is notified to the AAAH 1 00 by 
using an HAA (Home-Agent-M IP Answer: registration 
reply) message. At this time, the HAA message may In- 

20 ■■ dude the service profile infomiatlon of the mobile node 
600. 

[0039] Procedural step 7 : Upon receipt of the HAA 
message, the AAAH 1 00 extracts necessary information 
from the above described AMR message or user profile, 

25 and generates service control Infonnation (a service 
profile table of a service control transaction 120). Addi- 
tionally, the AAAH 100 transmits to the AAAF 400 an 
AMA (AA-moblle-Node Answer: authentication reply) 
message as a message in reply to the AMR message. 

30 At this time, the above described service profile infor- 
mation is added to this AMA message. 
[0040] Procedural step 8: The AAAF 400 extracts 
necessary information from the AMA message, and 
generates service control information (a service profile 

55 table of a service control transaction 420). Additionally, 
the AAAF 400 forwards the AMA message to the foreign 
agent 500. 

[0041] Procedural step 9: The foreign agent 500 ex- 
tracts necessary information from the AMA message, 

40 and generates service control infomiatlon (a service 
profile table of a service control transaction 530). Fur- 
thermore, the foreign agent 500 transmits a registration 
reply message based on the AMA message, and trans- 
mits the generated message to the mobile node 600. In 

45 this way, the location registration procedure is complet- 
ed. Thereafter, the foreign agent 500 provides the mo- 
bile node 600 with a service by using received service 
control infonnation. 

[0042] As described above, the location of the mobile 
50 node 600 is always managed by the home^gent 200. 
Additionally, since the service control information forthe 
mobile node 600 is transmitted to the foreign agent that 
is to accommodate the mobile node 600, the mobile 
node 600 can receive a service equivalent to the PBN 
55 at any location where there Is the foreign agent. 

[0043] In the above described network, the packet ad- 
dressed to the mobile node 600 is once transferred to 
the home agent 200 in nonnal cases. Here, the home 
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agent 200 recognizes that the mobile node 600 is ac- 
connmodated by the foreign agent 600. Accordingly, the 
home agent 200 forwards a received pacl<et to the for- 
eign agent 500, which then forwards the pac!<et to the 
mobile node 600. 

2. Outline of the present invention 

[0044] For understanding of explanation, tenns are 
predefined. In the following description, an "individual 
service" indicates a set of services customized for each 
user. Additionally, a service entity (such as Diff-Serv, 
ANYCAST, etc.) configuring an individual service is re- 
ferred to simply as a "service" . In the meantime, a serv- 
ice that Is not customized for each user (such as a mo- 
bile IP stipulated by the IETF (Internet Engineering Task 
Force), etc.) is referred to as a "fundamental service". 
[0045] Fig. 3 Is a schematic diagram showing the net- 
work configuration according to one embodiment of the 
present invention. 

[0046] When a mobile node 600 moves to the com- 
munication area of a foreign agent 500, an AAAH 100 
extracts the service control infomnation corresponding 
to the mobile node 600 from a service control database 
300 as explained by referring to Fig. 2. Note that the 
information (servtee profile) for providing an individual 
service -requested by each user is stored in the service 
control'database 300 for each user. Then , the AAAH 1 00 
distributes the extracted service profile to the foreign 
agent 500. The format of the service profile Is unified 
regardless of a service type. That is, the service profile 
does not include service-dependent information. 
[0047] ■ The service profile distributed from the AAAH 
1 00 to tHe-'foreign agent 500 (and the home agent 200) 
is unified In a fomiat that can be processed by the func- 
tions that the foreign agent 500 and the home agent 200 
originally prepare. Here, the foreign agent 500 and the 
home agent 200 are implemented, for example, by rout- 
ers. In this case, the functions that the foreign agent 500 
and the home agent 200 originally prepare are, for ex- 
ample, (1 ) the function for routing a packet, (2) the func- 
tion for extracting a particular packet from among re- 
ceived packets, (3) the editing function for rewriting part 
of the information of a received packet, and the like. 
These functions are implemented, for example, by the 
process for referencing a table which stores routing In- 
formation, the process for making a matching between 
preset data and the header of a received packet, and 
the like. Accordingly, after editing or converting the in- 
formation forproviding each userwith an individual serv- 
ice into the information used when the above described 
processes are performed (such as the information for 
specifying a table to be referenced, the information for 
specifying a matching key, etc.), the AAAH 100 distrib- 
utes the edited information to the foreign agent 500 (and 
the home agent 200). 

[0048] The configurations of each foreign agent 500 
and each home agent 200 are fundamentally the same, 



and respectively include a service-independent function 
for controlling a fundamental service, and an individual 
service control function (SCF). The service profile dis- 
tributed from the AAAH 1 00 is processed by the individ- 
ual service control function. At this time, the service pro- 
file is written or converted in a format which can be proc- 
essed by the function that the foreign agent 500 origi- 
nally prepares. Accordingly, the foreign agent 500 can 
use the received service profile unchanged without ed- 
iting it. The service-independent function and the indi- 
vidual service control function cooperate with each oth- 
er, so that the foreign agent 500 provides a service ac- 
cording to the service profile. 

[0049] If the location registration procedure of the mo- 
bile IP, the hand-off (handover) procedure of a mobile 
node, or a route optimization procedure and the above 
described functions are made to cooperate with one an- 
other, it becomes possible to control an individual serv- 
ice while taking full advantage of the functions specific 
to the mobile IP. 

3, Configuration of a system of the present invention 

[0050] Fig. 4 is a block diagram showing the functions 
of the embodiment according to the present invention. 
The functions are respectively explained below by re- 
ferring to Fig, 4. 

[0051] A service provider (home network) 50, an ac- 
cess provider (foreign network) 60, and a correspondent 
node 700 are Interconnected via an IP network 80 (or a 
mobile IP. 

[0052] The service provider 50 includes an AAAH 
100, a service control database 300 and a home agent 
(HA) 200. The connection between the AAAH 100 and 
the HA 200 is made, for example, by using an AAA pro- 
tocol. Additionally, the AAAH 1 00 accesses the service 
control database 300 by using a predeitermined data- 
base search protocol. The database search protocol is, 
for example, an LDAP (Light Directory Access Protocol) 
although it is not particulariy limited. 
[0053] The access provider 60 includes an AAAF 400 
and a foreign agent (FA) 500. The connection between 
the AAAF 400 and the FA 500 is made, for example, by 
using the AAA protocol. In Fig. 4, a mobile node (MM) 
600 Is currently accommodated by the FA 500 with the 
mobile IP. The connection between the AAAH 100 and 
the AAAF 400 is made with the AAA protocol. 
[0054] The AAAs (the AAAH 1 00 and the AAAF 400) 
are servers which perform authentication, authorization, 
and accounting. The configurations of the AAAH and the 
AAAF are fundamentally the same. The AAA that can 
access the database to which the subscriber data of a 
particular user is registered is referred to as an AAAH, 
and other AAAs are referred to as AAAFs, when atten- 
tion is focused on the particular user. 
[0055] The AAAH 1 00 has a function for notifying the 
HA 200 and the FA 500 of service profile infomnation. 
The service profile infomnation Is extracted from the 
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service control database 300 by a service managing 
unit. That is, the service managing unit of the AAAH 1 00 
extracts from the sen/ice control database 300 the serv- 
ice profile of the user who issues an authentication re- 
quest, and generates a service profile having a general- 
purpose fomnat in which packet control infonnatlon can 
be set. The service profile is notified to the HA 200 by 
using an HA registration request message (HAR), and 
to the FA 500 by using an authentication reply message 
(AM A), Furthermore, the AAAH comprises an ANY- 
CAST address management table for an ANYCAST 
service to be described later. In the meantime, the AAAF 
identifies the AAAH according to the NAI of a user, and 
performs a message exchange between the FA and the 
AAAH as a proxy. 

[0056] Furthermore, the AAA according to the present 
invention executes the hand-off between ISPs, details 
of which have not yet stipulated by the IETF, and holds 
an extended session transaction for keeping the rela- 
tionship with another entity to maintain the consistency 
of service control while a user is connected. Note that a 
protocol controlling unit is an Interface for the AAA pro- 
tocol. 

[0057] The HA and the FA fundamentally have the 
same configuration, and are functional entities which 
are respectively defined by the RFC2002. If attention is 
focused on a certain mobile node, an agent whbh has 
the home address assigned to the mobile node is an 
HA, whereas an agent which does not have the home 
address assigned to the mobiie node is an FA. 
[0058] Upon receipt of a packet to which the home ad- 
dress of a mobiie node is assigned as a destination, the 
HA encapsulates the packet and transmits the packet 
to the care-of address of the FA, which corresponds to 
the home address. This address Is originally managed 
by a table referred to as mobility binding. Additionally, 
the HA is an AAA protocol client. Furthemriore, the HA 
comprises a service-independent unit for executing the 
above described functions, a service profile cache for 
storing a service file set in the registration request (HAR) 
infonnation from the AAAH, and an individual service 
controlling unit for performing packet control by refer- 
encing a search policy management table which defines 
the search policy of the service profile cache. 
[0059] The FA decapsuiates the packet which Is en- 
capsulated and transmitted, and forwards this packet to 
the link layer address corresponding to the home ad- 
dress. This address is originally managed by a table re- 
ferred to as a visitor list. The FA is an access router of 
a mobile node, and is also an AAA protocol client at the 
same time. The FA further comprises a service-inde- 
pendent unit for executing the above described func- 
tions, a sen/ice profile cache for storing a service profile 
set in an authentication reply (AM A) message from the 
AAA, an individual service controlling unit for performing 
packet control by referencing a search policy manage- 
menttable which defines the search policy of the service 
profile cache, and an ANYCAST table which is a visitor 
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list extended to store the Information for an ANYCAST 
service. 

[0060] The HA and the FA respectively comprise a 
session transaction for managing a DIAMETER ses- 

5 sion. A protocol controlling unit is an interface for the 
AAA protocol and the mobile IP. A packet controlling unit 
performs packet routing, filtering, header rewrite, etc. 
[0061 ] The mobile node (MN) 600 Is a mobile terminal 
having thefunctlons fortransmitting and receiving pack- 

10 ets with the mobile IP. The correspondent node (CN) 
700 transmits/receives packets to/from the mobile node 
600. Also the correspondent node 700 comprises a 
service-independent unit, an individual service control- 
ling unit, a protocol controlling unit, and a packet con- 

15 trolling unit. ^ 

[0062] The mobile IP (MIP) is a protocol stipulated by 
the RFC2002. The mobile IP refen-ed to in this specifi- 
cation includes extensions that can possibly be stipulat- 
ed in the future. The format of the mobile IP is shown in 

20 Figs. 61 through 66. 

[0063] Fig. 61 shows the format of a mobile IP mes- 
sage. The IP header and the UDP header of this mes- 
sage are shown in Figs. 62A and 62B respectively. TOS 
(Type of Service), a source address, a destination ad- 

2s dress, etc. are set in the IP header, whereas a source 
port, a destination port, etc. are set In the UDP header. 
[0064] Fig. 63A shows the format of a mobile IP reg- 
istration request message. This message is used be- 
tween a mobile node and a foreign agent. Fig. 63B 

30 shows the fonnat of Registration Request within the reg- 
istration request message. The Registration Request in- 
cludes Lifetime, Home Address, Home Agent, Care-of 
address, Identifier, etc., and further includes an exten- 
sion area. 

35 [0065] Rg. 630 shows the format of the extension ar- 
ea (Mobile Node NAI Extension) shown In Fig. 63B. In 
this extension area, the NAI of a mobile node is set. Fig. 
63D shows the format of the extension area (Previous 
Foreign Agent Notification Extension) shown in Fig. 

40 63B. In this extension area, the lifetime of a cache, the 
address of a previous foreign agent, a new care-of ad- 
dress, etc, are set. 

[0066] Fig. 64A shows the format of a mobile IP reg- 
istration reply message. This message is used between 

45 a mobile node and a foreign agent. Fig. 64B shows the 
format of Registration Reply within the registration reply 
message. The Registration Reply includes a lifetime, a 
home address, a home agent, an identifier, etc., and fur- 
ther includes an extension area. 

50 [0067] Fig. 65 shows the format of a mobile IP BU 
(Binding Update) message. This message is used be- 
tween foreign agents, and between a home agent and 
a correspondent node. Fig. 66 shows the format of a 
mobile IP BA (Binding Acknowledge) message. Also 

55 this message is used between foreign agents, and be- 
tween a home agent and a correspondent node. 
[0068] The AAA protocol is not particularly limited. 
However, the D Iam ETER protocol that is currently being 
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reviewed by the IETF is assumed to be used in the em- 
bodiments. The AAA protocol is available to all of pro- 
tocols that can transmit the information about authenti- 
cation, authorization, accounting, and policies. The 
service profile information according to the present in- 
vention Is transmitted with an extensible attribute pa- 
rameter that Is referred to as an AVP (Attribute Value 
Pair) defined by the DIAMETER protocol. The extended 
attribute is service profile infomiation. 
[0069] Fig . 67 shows the format of a DI AM ETER mes- 
sage. The common header of this message is shown in 
Fig. 68. Here, Identifier uniquely Identifies a relation be- 
tween Registration Request and Registration Reply. 
[0070] Fig. 69A shows the fundamental fonnat of the 
DIAIV^ETER AVP (Attribute Value Pair). If AVP code=256 
is set In this fundamental fonnat, a DIAMETER com- 
mand Is generated. The fonnat of the DIAMETER com- 
mand is shown in Fig. 69B. The value corresponding to 
a message is set in a command code. Fig. 69C shows 
the fomnat of a general AVP other than the^DIAMETER 
command. 

[0071] Fig. 70 shows the fonnat of an AMR message 
of the DIAMETER protocol. This message is used be- 
tween a foreign agent and an AAAH server. Fig. 71 
shows the fomnat of an HAR message of the DIAMETER 
protocol. This message is used between an AAAH serv- 
er and a home agent. 

[d072]\ .Fig. 72 shows the fonnat of an AMA message 
of the DIAMETER protocol. This message is used be- 
tween a foreign agent and an AAAH server. Fig. 73 
shows the fonnat of an HAA message of the DIAMETER 
protocol. This message is used between an AAAH serv- 
er and a home agent. 

4. Configuration of AAAH 

[0073] Fig. 5 is a block diagram showing the functions 
of an AAAH. Here, authentication, authorization, and ac- 
counting functions are omitted. 

[0074] AnAAAH 100 extracts from a service control 
database 300 a service profile corresponding to a user 
who issues an authentication request, for example, up- 
on receipt of an authentication request (AMR) message, 
and distributes the extracted service profile to an HA and 
an FA. Namely, the AAAH acts as a server in a system 
which provides a mobile communications service. 
[0075] The AAAH 1 00 comprises a service managing 
unit 1 02 and a protocol controlling unit 1 01 . The protocol 
controlling unit 101 generates a session transaction for 
managing a DIAMETER session. The service managing 
unit 102 generates a service profile by referencing the 
service control database 300. Furthermore, the service 
managing unit 1 02 comprises the management table for 
managing a particular group in order to provide a serv- 
ice. Here, the service managing unit 1 02 comprises, for 
example, an ANYCAST address management table as 
a managernent table. 

[0076] Fig. 6 exemplifies the original data of a sen/ice 
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profile stored in the sen/ice control database 300. In the 
service control database 300. the subscriber informa- 
tion of each user (including a service profile) is stored 
by using the N Al of a user as a key. As an SLA (Service 

5 Level Agreement: a contract condition of a subscriber), 
for example, the service qualities shown In Fig. 7, the 
accounting method shown in Fig. 8, the restriction con- 
ditions shown In Fig. 9, etc. are set. As an individual 
service, for example, Diff-Serv, packet filtering, ANY- 

10 CAST, multicast, etc. can be set. Here, the profile for the 
Diff-Serv service is shown in Fig. 1 0, and the profile for 
the ANYCAST service is shown In Fig. 11 . 
[0077] Rg. 1 2 exemplifies the service profile generat- 
ed by the service managing unit 1 02 of the AAAH 1 00. 

15 This service profile is obtained by editing the data ex- 
tracted from the service control database 300, and dis- 
tributed to an HA arid an FA. 

[0078] The service profile is composed of a profile 
identifier, target packet control information, routing/ 

20 packet editing information, and Individual control infor- 
mation . The profile Identifier is a value for uniquely iden- 
tifying a service profile in a network. The target packet 
control information Is filter information for classifying a 
received packet. The routing/packet editing information 

25 is editing Information of an IP header, which is applied 
to the packet that hits the target packet control infomna- 
tion, and Information indicating the forwarding destina- 
tion of the packet. The Individual control infonnation In- 
dicates a service-specific control table^ that is pos- 

30 sessed by a service-independent unit, and is to be 
searched next for the packet which hits the target packet 
control infonnation. 

(1) profile identifier 

35 

[0079] "profile identifier" is composed of a session 
identifier and a profile number. The session identifier is 
a session ID, whereas the profile number is a value that 
is uniquely assigned to each session. The profile iden- 
40 tifier is shared by respective entities (AAAH, AAAF HA, 
FA, etc.), and is used to determine a service profile re- 
lating to a user session, and to Identify a specific service 
within a user session. As a session ID, for example, a 
session ID used In a DIAMETER session ID-AVPJs uti- 
45 \\ze6. The session ID is represented by using the NAI of 
a mobile node as follows in this embodiment. 
<NAI of rk/IN><32-blt value)<option> 

(2) target packet control information 

so 

[0080] 'target packet control information" is com- 
posed of the IP address of a transmission source, the 
IP address or a destination, the port number of the trans- 
mission source, and the port number of the destination. 
55 If part of the bits of the IP address is set to "don't care", 
. this part is represented by a wildcard as follows. 
172.27.180.* 
172.27.*.* 
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[0081] It is not necessary to set all of these four val- 
ues. When a received packet Is extracted according to 
target packet control information, a hit Is recognized to 
occur* for example, on the condition that all of set values 
match all of the corresponding values set in the received 
packet. 

(3) routing/packet editing infomiation 

[0082] "encapsulation (encryption) method" specifies 
an encapsulation method to be executed when a packet 
is encapsulated not by a service-independent function. 
The information for encapsulating a packet by a service- 
independent function is set in an HA or an FA. 
[0083] "transfer destinatton address" specifies a des- 
tination address when a packet is transferred not by the 
service-independent function, A plurality of addresses 
can be specified as "transfer destination address". Ad- 
ditionally, if a packet is transferred to the care-of address 
of a mobile node, the packet transfer is made according 
to a mobility binding table to be described later. 
[0084] "TOS" specifies a value to be written to the 
TOS field of the packet received by the HA or the FA. If 
this value Is specified, the IP header of the packet that 
hits the above described target packet control informa- 
tion, and that of the packet edited by the service-inde- 
pendentf unction (such as a packet encapsulated by ref- 
erencing the mobility binding table) are rewritten. 
[0085] "decapsulation instruction" specifies whether 
or not to decapsulate a packet that hits the above de- 
scribed target packet control information If it is encap- 
sulated. The decapsulation process Is executed before 
an Individual control table is searched. 

(4) Individual control infomiation 

[0086] "Individual control Infomnatlon" is composed of 
service control type infomnatlon and a control informa- 
tion identifier. The service control type information is in- 
tended to instruct the control table to be accessed by 
the HA or the FA. The control table arranged in the HA 
or the FA is. for example, a service profile cache, control 
data specific to the mobile IP (a binding cache, mobility 
binding, a visitor list), a routing table, and service-spe- 
cific control data (an ANYCAST table, etc.). The control 
Infonnation Identifier Indicates the link destination of the 
control table accessed according to the service control 
type information. The control information Identifier is, for 
example, an identifier for identifying or a pointer pointing 
; to an entry of each control table. 
[0087] The AAAH 1 00 generates the service profile 
shown in Fig. 1 2 based on the original data of the service 
profile shown in Figs . 6 through 11 . A method generat- 
ing a service profile is not particularly limited. However, 
a service profile can be generated based on the type 
and the contents of a service requested by a user. For 
example, If a user requests the Diff-Serv service, the IP 
address, the port number, etc., which are shown in Fig. 
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10, may be set in the target packet control Infomiation. 
Additionally, the TOS may be set based on a search ex- 
pression and a service class of a DIff-Sen/ policy Or, If 
an ANYCAST service is requested, an ANYCAST table 

5 may be specified in the service control type infomnatlon, 
and at the same time, target packet control Information 
may be set based on an ANYCAST address. 
[0088] As described above, the service profile Is al- 
ways in the same format regardless of the type of a serv- 

10 Ice to be provided to a user. Namely, the entire informa- 
tion for providing an individual service is stored in the 
format shown In Fig. 12 and distributed to the HA and 
the FA. 

[0089] Fig. 13 exemplifies an ANYCAST address 
IS management table arranged In the AAAH 1 00. This ta- 
ble is configured In units of ANYCAST address blocks. 
Each of the blocks includes an ANYCAST address, one 
or more NAIs conresponding to the ANYCAST address, 
the home address of the terminal identified by each NAi, 
and the state of th e term Inal identified by each NAI . The 
state of the tenninal Is, for example, an online, an offline, 
a pending, a faulty, a congested state, etc. 
[0090] Fig. 14 exemplifies the session transaction of 
the AAAH. The session transaction is generated and 
25 held to transmit/receive a DIAMETER message and to 
maintain the link with a service profile. The session 
transaction of the AAAH includes a session ID, an HA 
address, the address of the current AAAF, the address 
of the AAAF which transmits an AMR message, security 
30 infonnation, a session timer, and service profiles. 

5. Configuration of AAAF 

[0091] Fig; 15 is a block diagram showing the func- 
35 tions of an AAAF, Upon receipt of an authentication re- 
quest (AMR) message from a mobile node, an AAAF 
400 forwards this message to an AAAH 100, Upon re- 
ceipt of a service profile from the AAAH 1 00, the AAAF 
400 distributes the sen/ice profile to an FA 600. The 
40 AAAF 400 can also specify an HA. In this case, the 
AAAF 400 distributes the service profile to an HA 200 
and the FA 500 upon receipt of the service profile from 
the AAAH 100. 

[0092] The AAAF 400 comprises a protocol control- 
ling unit 401 . The protocol controlling unit 401 generates 
a session transaction for managing a DIAMETER ses- 
sion, The session transaction of the AAAF Includes a 
session ID, an AAAH address, an HA address, the NAI 
of a previous FA, the NAI of a current FA, security infor- 

50 mation, a session timer, a service profile, and a trans- 
action state as shown in Fig. 1 6. 
[0093] Note that the AAAF fundamentally has the 
same configuration as that of the AAAH. Accordingly, 
the AAAF acts as a server in a system that provides a 

55 mobile communications service, similar to the AAAH. 
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6. Configurations of HA, FA, and CN 

[0094] Fig. 17 is a block diagram showing the func- 
tions of an HA, an FA. and a CN. The HA, FA, and CN 
fundamentally have the same configuration, and re- s 
spectiveiy comprise a packet controlling unit 201 , a pro- 
tocol controlling unit 202, an individual service control- 
ling unit 203, and a service-independent function unit 
204. 

[0095] The packet controlling unit 201 has the func- io 
tion forf lltering a packet, and classifies received packets 
Into protocol packet and data packet by decoding the 
header of each packet. Upon receipt of a protocol pack- 
et, the packet controlling unit 201 requests the protocol 
controlling unit to process the packet. Upon receipt of a 
data packet, the packet controlling unit 201 passes the 
Information required for processing the packet to the In- 
dividual service controlling unit 203. The packet control- 
ling unit 201 edits the packets (rewrites their headers, 
etc.), and forwards the packets according to the instruc- 20 
tlons from the individual service controlling unit 203 and 
the service-independent function unit 204. 
[0096] The protocol controlling unit 202 is a unit 
processing the mobile IP and the DIAMETER protocol, 
and sets necessary infomnation (such as the information 25 
for location registration, etc.) In the service-independent 
function unlt204 in compliance with the protocol. Addi- 
tionally, the protocol controlling unit 202 generates a 
session transaction for managing a DIAMETER ses- 
sion. The session transaction of the HA and the FA Is 30 
shown in Fig. 18. Furthermore, if a service profile Is no- 
tified from an AAA, the protocol controlling unit 202 
stores the service profile in the service profile cache of 
the individual sen/ice controlling unit 203. 
[0097J The individual service control ling unit 203 com- 35 
prises a sen/ice profile cache 211 being a set of sen^ice 
control information, and a search policy management 
table 212 in which the poltey for searching the service 
profile cache 21 1 is set. 

[0098] Fig. 19 exemplifies the service profile cache 40 
211 . The service profile cache is composed of an indi- 
vidual node SPG (NSPC) and an AAA-notifiedSPC (AS- 
PC). The individual node SPG is a service profile cache 
that the HA, the FA, or the CN comprises beforehand, 
and Is composed of a source service profile (NSPCsrc), 
a source default service profile (NDSPsrc), a destination 
service profile (NSPCdst), a destination default service 
profile (NDSPdst), and a default service profile (NDSP). 
In the meantime, the AAA-notified SPC is a service pro- 
file cache distributed from the AAAH , and is composed so 
of a source profile (ASPCsrc) and a destination service 
profile (ASPCdst). The service profiles are mutually in- 
dependent. 

[0099] The service profiles are written in the format 
shown in Fig. 12. Namely, each of the service profiles ss 
includes (1 ) the information (target packet control infor- 
mation) for extracting a particular packet from among 
received packets, (2) the Infomnation (routing/packet ed- 



iting information) for editing an extracted packet, and (3) - 
the Infomnation (Individual control information) for refer- 
encing corresponding table arranged in the service-in- 
dependent unit 204. Rg. 12 shows the service profile 
distributed from the AAA to the HA or the FA. Also the 
service profile that is arranged as an individual node 
SPC beforehand In the HA or the FA has the same con- 
figuration. Namely, if the AAAH extracts the original data . 
of a sen/ice profile from the service control database, It 
edits the original data Into the samefonnat as that of the 
service profile that is arranged In the HA or the FA be- 
forehand, and distributes the service profile to the HA 
or the FA. 

[0100] In the target packet control information of the 
source SPC {NSPCsrc and ASPCsrc) and the source 
default SP (NDSPsrc), at least either of the source ad- 
dress and the source port number Is set. Accordingly, 
the packet transmitted from a particular transmission 
source or source port is processed according to the 
service profile. Furthermore, at least either of the desti- 
nation address and the destination port number is set in 
the target packet control infomnation of the destination 
SPC (NSPCdst and ASPCdst) and the destination de- 
fault SP (NDSPdst). Therefore, the packet proceeding 
to a particular destination or destination port Is proc- 
essed according to the service profile. The default SP 
(NDSP) is arranged to process the packet that Is not 
processed according to any of the above service pro- 
files. 

[0101] When a data packet reaches the packet con- 
trolling unit 201, the Individual sen^ice controlling unit 
203 determines the service profile for processing the 
packet. The method selecting a predetennined service 
profile from the service profile cache 211 is described in 
a search policy management table 212. 
[01 02] Fig. 20 exemplifies the search policy manage- 
ment table 212. The search policy management table 
211 manages a search policy (search order) for search- 
ing the service profile cache 211 . The search policy Is 
not particularly limited. However, it is written so that a 
search range is widened, for example, from a service- 
specific profile to a shared service profile. 
[01 03] If the service profile cache 21 1 is searched with 
the search policy management table 212 shown in Fig. 
20, the target packet control Infomiation of the source 
SPC (ASPCsrc) distributed from an AAA Is first extract- 
ed. Then, the source address and the source port 
number, which are set in the target packet control infor- 
mation, are respectively compared with the source ad- 
dress and the source port number within a i;eceived 
packet. If these addresses and port numbers respec- 
tively match at this time, the table of the service-inde- 
pendent unit 204 is referenced according to the source 
SPC (ASPCsrc). If the corresponding Information is 
stored in the referenced table, the received packet is 
processed according to this information. If the corre- 
sponding information is not stored in the referenced ta- 
ble, the process Is temnlnated by recognizing that a fault 
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occurs. If at least either of the source addresses and the 
source port numbers do not match, the source SPC 
(NSPCsrc) preset in the HA, the FA. or.the CN is ex- 
tracted. 

[0104] The process perfomied when the source SPC 
(NSPCsrc) is extracted Is fundamentally the same as 
that perfonmed when the source SPC (ASPCsrc) distrib- 
uted from the AAA is exracted. Namely, if the source 
addresses and the source port numbers match respec- 
tively, a received packet is processed by referencing the 
table of the service-Independent unit 204 according to 
the source SPC (NSPCsrc). if corresponding infomria- 
tion is not stored in the table of the service-independent 
unit 204 although the source addresses and the source 
port numbers match respectively, a source default SP 
(NDSPsrc) is extracted. 

[0105] The above described process Is repeated in a 
similar manner until the service profile in which the same 
address and port number as those of the received pack- 
et are found according to the search policy management 
table 21 2. If the corresponding service profile cannot be 
found despite the execution of the procedural steps 1 
through 4 in the search policy management table 212 
shown in Rg. 20, a default SP (NDSP) Is extracted in 
the procedural step 5. The packet is then processed ac- 
cording to the default SP (NDSP). 
[0106] As described above, the service profile in 
which the same address and port number as those of a 
data packet are set is extracted upon arrival of the data 
packet, and the packet Is processed according to the 
service profile. At this time, the HA, FA, and CN can 
process the received packet only by referencing the ta- 
ble of the service-independent unit 204 according to the 
service file distributed from an AAA, or a prearranged 
service profile. Namely, the HA, FA, and CN can provide 
an individual service for each user, which is stored in the 
service control database 300, by using the service pro- 
file distraautedfrom the AAA unchanged. 
[01 07] The service-independent unit 204 comprises a 
visitor list, mobility binding, a binding cache, an ANY- 
CAST table, and a routing table. The visitor list, the mo- 
bility binding and the binding cache among them tables 
are control tables for managing the mobile IP. The rout- 
ing table is a packet control table that a router originally 
comprises. The ANYCAST table is a control table that 
Is an-anged to execute an ANYCAST service being a 
value-added service. 

[0108] Fig. 21 exemplifies the visitor list. The visitor 
list, which is arranged in the FA, is a table for making a 
correspondence between the IP address (home ad- 
dress) of a mobile node and the link layer address (such 
as an MAC address) of the mobile node. 
[0109] Fig. 22 exemplifies the mobility binding. The 
mobility binding, which is arranged in the HA: is a table 
for making a correspondence between the IP address 
(home address) of a mobile node and the address (care- 
of address) of the FA that accommodates the mobile 
node. The mobility binding Is referenced when the HA 



receives the packet addressed to the mobile node. In 
this case, the care-of address that corresponds to the 
IP address of the packet Is extracted, and the packet is 
encapsulated and fonwarded to the FA having the ex- 
5 tracted care-of address. It should be noted that the mo- 
bility binding is updated, for example, when the mobile 
node moves from the communication area of one FA to 
that of another 

[0110] Fig. 23 exemplifies the binding cache. The 
10 binding cache, which is arranged In the FA and the CN, 
is a routing table that is temporarily used to improve the 
transfer efficiency of a packet. The binding cache is giv- 
en higher reference precedence than that of the routing 
table. 

15 [0111] Rg. 24 exemplifies the ANYCAST table. The 
ANYCAST table, whteh is an^anged in the FA, stores the 
Infomnatlon required to provide an ANYCAST sen^ice. 
. The ANYCAST table is obtained, for example, by addi- 
tionally registering an ANYCAST address and the ad- 

20 dress of an address proxy server having the ANYCAST 
address. 

[01 12] Fig. 25 exemplifies the routing table. The rout- 
ing table, which is arranged in the HA, FA, and CN, is 
used to obtain the next hop address (such as the next 
25 router) as a transfer destination, to which a packet is to 
be transferred, based on the destination address stored 
in the header of the received packet. 

7. Sequence for distributing service profiles 

30 

[0113] The essence of an IP service is condensed into 
a target packet selection, packet editing, and routing 
destination determination. According to the present in- 
vention j the editing process of service control informa- 

35 tion for each service Is executed by an AAAH, and gen- 
eralized packet editing information is distributed to a mo- 
bile agent (such as an FA), As a result, the mobile agent 
can use the distributed service profile as packet control 
Information unchanged, leading to the speed-up of the 

40 process. 

[0114] Additionally, according to the present Inven- 
tion, the configuration of a service profile cache being a 
set of service profiles, and a method searching the serv- 
ice profile cache are systematized. In the HA and the 

45 FA according to the present Invention , the service-inde- 
pendent unit which perfomris packet control based on 
the mobile IP, and the individual sen^ice controlling unit 
which uses the service-independent unit based on a 
service setfor each user are separated. Accordingly, for 

so example, if a service Is added/changed, there Is no fun- 
damental need to rewrite the program or the data of the 
service-independent unit, and the only operation that 
must be performed is to update the settings of the indi- 
vidual service controlling unit. That Is, service addition, 

55 change, implementation, etc. are expected to become 
easy. 

[0115] Furthemnore, according to the present inven- 
tion, a service profile managing method which enables 
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service control within the framework of the nnessages 
stipulated by the existing mobile IP Is devised. 
[01 1 6] Hereinafter, the case where the Diff-Serv serv- 
ice is applied to the mobile IP is adopted as a embodi- 
ment. ^ 
[0117] In the embodiments according to the present 
invention, an HA may be specified either by an AAAH 
or by an AAAF. Described below are the case (A) where 
an AAAH specifies an HA, and the case (B) where an 
AAAF specifies an HA; 

7 A. Case where an AAAH specifies an HA 

[0118] Described in the following embodiment are (1) 
the sequence at the time of an initial registration, (2) the is 
sequence in the case where a mobile node moves from 
the communication area of one FA within a certain AAAF 
to that of another FA, and (3) the sequence In the case 
where a mobile node moves from the communication 
area of an FA within one AAAF to that of an FA within 
another AAAF. 

7A (1) Sequence at the time of an initial registration 

[01 1S] Fig. 26 shows the sequence for distributing 25 
service profiles. Illustrated here is the sequence after 
the advertisement message that an FA 500 periodically 
outputs is received by a mobile node 600. In this figure, 
messages Succeeded by an asterisk indicate that a 
service profile is attached. 

[0120] The mobile node 600 transmits a registration 
request (Reg-Req) message to the FA 500. Upon re- 
ceipt of the Registration request (Reg-Req) message, 
the FASOb transmits an authentication request (AMR) 
message to an AAAF 400. Upon receipt of the authen- 
tication request (AMR) message, the AAAF 400 for- 
wards this message to an AAAH 1 00 of the mobile node 
600. Upon receipt of the authentication request (AMR) 
message, the AAAH 1 00 extracts the original data of the 
service profile of the mobile node 600 from a service 
control database 300, and edits the data into a fonnat 
that is available to an HA 200 and the FA 500 un- 
changed. The AAAH 1 00 then transmits to the HA 200 
the edited service profile by using a registration request 
(HAR) message. As a result, the HA 200 generates mo- 
bility binding (including the infomnation indicating that 
the mobile node 600 is accommodated by the FA 500), 
and adds the received service profile to a service profile 
cache at the same time. 

[01 21 ] Then, the HA 200 transmits a registration reply 
(HAA) message to the AAAH 100. Upon receipt of the 
registration reply (HAA) message, the AAAH 100 trans- 
mits the service profile to the AAAF 400 by using an au- 
thentication reply (AM A) message. Upon receipt of the 
authentication reply (AMA) message, the AAAF 400 
transmits the service profile to the FA 500 by using the 
authentication reply (AMA) message. As a result, the FA 
500 generates a visitor list (including the information in- 
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dicating that the mobile node 600 Is accommodated by 
the FA 500). and adds the received service profile to a 
service profile cache. Then, the FA 500 returns a regis- 
tration reply (Reg-Resp) message to the mobile node 
600. 

[01 22] As described above, the servtee profile indicat- 
ing the individual service for the mobile node 600 is dis- 
tributed to the HA 200 and the FA 500 when the location 
registration sequence of the mobile node 600 is execut- 
ed. Accordingly, the mobile node 600 can receive the 
Individual service, which is contracted beforehand, 
while being accommodated by the FA 500. 
[0123] Next, the above described sequence is ex- 
plained in detail. First assume that the service profiles 
are respectively generated and stored in the service pro- 
file caches when the HA and the FA are initially config- 
ured, as shown In Fig. 27. Additionally, routing tables 
are set by a network management system or a routing 
protocol. Since a method generating a routing table 
does not directly relate to the present invention, its ex- 
planation is omitted here. 

[0124] Figs. 28A and 28B exemplify the sen/ice pro- 
files generated by the FA at the time of an initial config- 
uration. The service profile shown in Fig. 28 A represents 
that the routing table is referenced when the route of a 
received packet is determined. The service profile 
shown in Fig. 28B represents that the cache shown in 
Fig. 28A is referenced after a decapsulation process is 
executed, upon receipt of a packet in vyhich the FA 500 
is set as a destination address. 
[01 25] Fig. 29 exemplifies the service profile generat- 
ed by the HA at the time of an initial configuration. This 
service profile represents that the routing table is refer- 
enced when the route of a received packet Is deter- 
mined. 

[0126] Fig. 30 shows the procedure for generating a 
service profile by the AAAH. 

(1 )-(4) Upon receipt of the registration request mes- 
sage transmitted from the mobile node 600, the FA 
500 generates a DIAMETER session transaction 
and a visitor list. The DIAMETER session transac- 
tion and the visitor list are, for example, the ones 
shown in Figs. 18 and 21 . The FA 500 then trans- 
mits a registration request (AMR: AA-Mobjle-Node- 
Request) message to the AAAF 400. 
(5) - (6) The AAAF 400 generates a DIAMETER 
session transaction. This transaction is, for exam- 
ple, the one shown in Fig. 16. Then, the AAAF 400 
identifies the authentication home server (AAAH 
100) of the user of the mobile node 600 based on 
the network identifier (NAI) of the user, which Is no- 
tified by the AMR message, and forwards the AMR 
message to the identified AAAH 100. 
(7)-(9) The AAAH 1 00 generates a DIAMETER ses- 
sion transaction. This transaction is, for example, 
the one shown in Fig. 14. The AAAH 100 then 
searches the servce control databaise by using as 
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a key the NAI of the user, which is notified by the 
AMR message, and extracts the original data of the 
service profile of that user. Furthermore, the AAAH 
1 00 generates a sen/Ice profile to be set in the HA 
200 and the FA 500 based on the information set In 5 
the original data of the service profile and a policy 
predetermined to edit a service profile. 

The service profile falls into two types: a desti- 
nation service profile the search condition of which 
Is destination information (such as a destination ad- io 
dress and a destination port number), and a source 
service profile the search condition of which Is 
source information (such as a source address and 
a source port number). As an Identifier of each serv- 
ice profile, a session ID and an arbitrary profile is 
number are set. Furthennore. the service profile 
may be managed, for example, under the following 
conditions: (1) if both of destination information and 
source information are used as search information, 
they are set in a source service profile; (2) the 
source service profile and the destination service 
profile are generated for each service type to be 
provided; and (3) the source service profile is ap- 
plied with higher precedence than the destination 
service profile. 25 

Figs, 31 A and 31 B exemplify the service pro- 
files to be distributed to the HA. The service profile 
in which destination Information is set as a search 
condition is shown In Fig. 31 A, whereas the sen/ice 
profile in which source information Is set as a search 30 
condition Is shown in Fig. 31B. 

Figs. 32A and 328 exemplify the service pro- 
files to be distributed to the FA. The service profile 
in which destination information is set as a search 
condition is shown In Fig. 32A, whereas the service 35 
profile In which source information is set as a search 
condition is shown in Fig. 32B. 

These service profiles are generated based on 
the information set in the original data of the service 
profiles, and the policy predetermined to editaserv- 40 
Ice profile, as described above. For example, If the 
service profile (see Fig. 31 A) for the user who re- 
quests the Diff-Serv service, which is to be distrib- 
uted to the HA, is generated, the address and the 
port number of the mobile node that the user uses 45 
are respectively set as a destination address and a 
destination port number. Additionally, the TOS val- 
ue that is determined at the time of subscription to 
the Diff-Serv service is set in "TOS". Furthermore, 
a mobility binding table Is set In "Individual control ^ 
information" so as to forward the packet addressed 
to the mobile node to the FA which accommodates 
that mobile node. 

Fig. 33 shows the procedure for setting service 
profiles in the HA. 55 
(1 0) The AAAH 1 00 attaches a destination sen/ice 
profile (MN-HAdest) and a source service profile 
(MN-HAsrc) to a registration request (HAR: Home- 



Agent-M IP-Request) message, and transmits this 
message to the HA 200. 

(11)- (1 2) The HA 200 generates a D I AMETER ses- 
sion transaction, and adds the notified service pro- 
files to the service profile cache at the same time. 
This transaction is, for example, the one shown In 
Fig. 18. Additionally, the HA 200 generates mobility 
binding based on the information set in the HAR 
message. The mobility binding is, for example, the 
one shown in Fig. 22, Then, the information for link- 
ing with the generated mobility binding Is set as a 
"control information identifier" of the destination 
sen/lce profile (MN-HAdest). 

Fig, 34 exemplifies the procedure for transfer- 
ring sen/ice profiles to the AAAF. 

(13) Upon termination of the settings of the service 
profile cache, and the process for the HARmes- 
sage, the HA 200 returns a registration reply (HAA: 
Home-Agent-MIP-Answer) message to the AAAH. 

(1 4) The AAAH 1 00 attaches the destination service 
profile (MN-FAdest) and the source sen/ice profile 
(MN-FAsrc) to an authentication reply (AMA: AA- 
Mobile-Node-Answer) message, and transmits this 
message to the AAAF 400. 

Then, the AAAF 400 holds the service profiles 
transmitted by using the AMA message by linking 
with the session transaction for the hand-off proc- 
ess within the same domain. 

Fig. 36 shows the procedure for setting service 
profiles In the FA. 

(1 5) The AAAF 400 attaches the destination service 
profile (MN-FAdest) and the source service profile 
(MN-FAsrc) to the authentication reply (AMA: AA- 
Moble-Node-Answer) message, and transmits this 
message to the FA 500. 

Then, the FA 500 adds the notified sen^ice pro- 
files to the service profile cache. At this time, the 
destination sen/ice profile (MN-FAdest) and the 
source service profile (MN-FAsrc) are respectively 
added, for example, to the "destination SPC (AS- 
PCdst)" and the "source SPC (ASPCsrc)" in the 
AAA-notified SPC shown in Fig. 1 9. Additionally, the 
information (the home address and the address of 
the HA 200) transmitted by the AMA message are 
set In the visitor list, Furthemnore, the destination 
sen/lce profile (MN-FAdest) and the visitor list are 
linked. 

(1 6) Upon termination of the generation of the serv- 
ice profile cache and the process for the AMA mes- 
sage, the FA 500 returns a registration reply mes- 
sage to the mobile node 600. 

[01 27] With the above described sequence, the serv- 
ice profiles are respectively set in the service profile 
caches of the HA 200 and the FA 500. Thereafter, the 
packet transmitted from the mobile node 600 to an ar- 
bitrary terminal (correspondent node CN 700), and the 
packet transmitted from the correspondent node CN 
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700 to the mobile node 600 are processed according to 
these service profiles. 

[0128] Fig. 36 shows the procedure for transferring a 
pacl<et from the mobile node to the correspondent node. 
Here, suppose that the Diff-Serv service is provided, 
and the service profile shown In Fig. 32 Is set In the FA 
500. . 

[0129] Upon receipt of the data packet addressed to 
the correspondent node CN 700, the FA 500 searches, 
the service profile cache in the order described in the 
search policy management table shown in Fig. 20. 
Namely, the FA 500 extracts the service profile (ASPC- 
src) shown in Fig. 32B. Because the "address of the mo- 
bile node 600" and the "address of the correspondent 
node 700" are respectively set as the source address 
and the destination address of the received packet, the 
source address set In the received packet and that In 
the extracted service profile match. Accordingly, the re- 
ceived packet is processed according to the service pro- 
file (ASPCsrc) shown in Fig. 32B. As a result, this packet 
Is routed according to the routing table after the TOS 
value Is set- 

[01 30] Fig. 37 shows the procedure for transferring a 
packet from the correspondent node to the mobile node. 
Also here, suppose that the Diff-Serv service is provid- 
ed, the service profile shown in Fig. 31 Is set in the HA 
200, ^nd the service profile shown in Fig. 32 Is set in the 
FA 500. ^ 

(1) The data packet addressed to the mobile node 
600 Is forwarded to the HA200. because Its address 
belongs to the segment of the HA 200. 

(2) Upon receipt of the data packet from the conre- 
■'^sp6rtdent-node CN 700, the HA 200 first searches 

the service profile (ASPCsrc) according to the 
search policy management table shown in Fig. 20. 
Here, It is assumed that the mobile node 600 can 
receive a packet from any tenninaL and no settings 
are made in the target packet control inf omnation in 
the service profile (ASPCsrc). In this case, the serv- 
ice profile (NSPCsrc) is then searched according to 
the search policy management table shown in Fig. 
20. For the above described reason, it is assumed 
that no "hit" occurs also in this case. 

(3) The HA 200 searches the sen^ice profile (AS- 
PCdst) in succession to the above described (2). 
Here, suppose that the service profile (ASPCdst) 
shown in Fig. 31 A is searched. Since the destina- 
tion address of the above described data packet 

V and that set in the target packet control information 
match In this case, the process Is to be executed 
according to this service profile. Here, in the service 
profile (ASPCdst), the TOS value Is set and mobility 
binding is specified as a link destination. 

(4) The HA 200 references the mobility binding, and 
encapsulates the packet to be forwarded to the FA 
500 according to the mobile IP procedure. Addition- 
ally, the HA 200 sets the TOS value in the encap- 



sulated packet. 

(5) Upon receipt of this data packet, the FA 500 
searches the service profile cache. Because the 
destination address of the encapsulated packet is 

5 "FA 500" In this case, this packet hits the mobile IP 
default sen/Ice profile shown in Fig. 28B. In this 
sen/ice profile, a decapsulation instruction Is set, 
and a sen/ice profile cache is set as a link destina- 
tion. Accordingly, the FA 500 again searches the 

10 service profile cache after decapsulating the re- 
ceived packet. 

[0131] As the destination address of the decapsulated 
packet, the "mobile node 600" is set. Accordingly this 

15 decapsulated packet hits the service profile (ASPCdst) 
shown in Fig. 32A. Furthemnore, a visitor list Is specified 
as a link destination In this service profile. Accordingly, 
the FA 500 fonwards the data packet to the link layer 
address of the mobile node 600 registered to the visitor 

20 list according to the mobile IP procedure. 

7A(2) Sequence In the case where the mobile node 
moves from the communication area of one FA within a 
certain AAAF to that of another FA 

25 

[0132] Fig. 38 shows the sequence for distributing 
service profiles. Illustrated here is the case where the 
mobile node 600 moves from the communication area 
of an FA 500p to that of an FA 500n. Assume that both 
30 of the FA SOOp and the FA 500n belong to the AAAF 400 . 

(1) When the mobile node 600 enters the commu- 
nication area of the FA 500n, it receives from the FA 
500n an agent advertisement in which an S bit 

35 (smooth hand-off bit) is set. 

(2) The mobile node 600 extracts the address of the 
FA that has transmitted the agent advertisement, 
and detemiines whether or not the domain portion 
of the NAl of the FA changes. Because both of the 

40 FA 500p and the FA 500n belong to the AAAF 400, 
the domain does not change. Accordingly, the mo- 
bile node 600 sets a "previous FA notification ex- 
tension" In a registration request message, and 
transmits the message to the FA 500n. The "previ- 

45 ous FA notification extension" is shown In Fig. 63D. 

(3) Upon receipt of the registration request mes- 
sage including the "previous FA notification exten- 
sion", the FA 500n generates a visitor list, and no- 
tifies the AAAF 400 of "Previous-FA-N Al-AVP" and 

so "MN-FA-SPI-AVP" to the AAAF 400 by using the 
AMR message shown in Fig. 70 in order to obtain 
a session key from the AAAF 400. The "Previous- 
FA-NAI-AVP" Identifies the FA SOOp in this case. 

(4) The AAAF 400 identifies a session according to 
55 the "MN-FA-SPI-AVP". The AAAp 400 then trans- 
mits to the FA 500n the AMA message In which the 
session key group identified by the session and the 
sen/ice profile are set. 
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(5) Upon receipt of the session key notified by the 
Al\4 A message, the FA 500n pert omis the authenti- 
cation of the mobile node 600 with this key. If the 
FA 600 successfully perforn\s the authentication of 
the mobile node, ft generates a service control 5 
transaction, and transmits a binding update mes- 
sage to the FA 500p. Here, an "A bit" of the binding 
update message must be set without fail. Addition- 
ally, route optimization authentication is used so 
that the FA perfonms the authentication of route op- io 
timlzatlon. Furthermore, a service profile linked to 
the visitor list of the FA 500n is set as the service 

' profile. However, the link destination is changed to 
a binding cache. 

(6) Upon receipt of the binding update message, the is 
FA 500p deletes the visitor list for the mobile node 
600, iand generates a binding cache. Additionally, 

the FA 500p sets the binding cache as a link desti- 
nation of the service profile. The FA 500p then 
transmits a binding acknowledge message to the 
mobile node BOO. The binding acknowledge mes- 
sage is encapsulated and transmitted to the FA 
500n, which decapsulates the message and for- 
wards the decapsuiated message to the mobile 
node 600, Thereafter, when the lifetime of the reg- 25 
istered cache expires, the FA 500p temriinates the 
provision of a service to the mobile node 600. 

(7) The FA 500n transmits the registration request 
message to the HA 200 with a normal procedure. 

(8) The HA 200 returns a registration reply message 30 
to the FA 500 n . Upon receipt of the registration reply 
message, the FA 500n gets ready to transmit data 

to the mobile node 600 thereafter. 

(9) The FA 500n returns the registration reply mes- 
sage to the mobile node 600. 35 

(10) The packet from the con-espondent node 700 
to the mobile node 600 is encapsulated and for- 
warded to the FA 500. After the packet is once de- 
capsuiated by the FA 500, it is again encapsulated 
and forwarded to the FA 500n . The FA 500n decap- 40 
sulates this packet, and fonnrards it to the mobile 
node 600. 



7A(3) Sequence in the case where the mobile node 
moves from the communication area of an FA within one 
AAAF to that of an FA within another AAAF 
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[0133] Fig, 39 shows the sequence for distributing 
service, profiles. Illustrated here is the case where the 
mobile node 600 moves from the communication area so 
of an FA 500p subordinate to an AAAF 40 Op to that of 
an FA 500n subordinate to an AAAF 400n. 

(1 ) When the mobile node 600 moves from the conv 
munication area of the FA 500p to that of the FA 55 
500n, the mobile node 600 receives from the FA 
SOOn the agent advertisement in which the S bit is 



(2) The mobile node 600 extracts the address of the 
FA that has transmitted the agent advertisement, 
and detemiines whether or not the domain portion 
of the NAI of the FA has changed. Since the FA 500p 
and the FA SOOn belong to the different AAAFs in 
this case, the domain has changed. Accordingly, the 
mobile node 600 sets "MN-AAA authentication" ih 
a registration request message, and transmits this 
message to the FA 500n. 

(3) The FA SOOn generates a visitor list. At this time, 
no corresponding session transaction exists. Ac- 
cordingly, the mobile node 600 sets "session ID=0" 
in the AMR message, and transmits this message 
to the AAAF400n. 

(4) The AAAF 400n forwards the AMR message to 
the AAAH 1 00 based on the NAI notified by the AMR 
message. 

(5) The AAAH 1 00 performs the following processes 
upon receipt of the AMR message. 

session merging process: upon receipt of the 
AMR message in which "session ID=0" Is set, 
the AAAH 1 00 searches a session transaction 
by using the NAI of the mobile node 600. If a 
hit is found in this search, the ID of this session 
Is used for the subsequent sequence. If a hit is 
not found, the AAAH 100 newly generates a 
session transaction, and assigns a session ID 
to the generated transaction. If the AMR mes- 
sage in which a session ID is set is received, 
the AAAH 1 00 searches the session transac- 
tion by using the received session ID. 
key group generation: The AAAH 1 00 regener- 
ates all of security keys, and updates a session 
timer. 

The AAAH transmits an HAR message to the 
HA 200 (a service profile transmission is arbi- 
trary when a session transaction is not gener- 
ated). 

(6) The HA 200 updates the mobility binding, and 
returns an AMA message to the AAAH 1 00. 

(7) The AAAH 1 00 makes a comparison between 
the AAAF that has transmitted the AMR message 
and the AAAF within the session transaction. If they 
mismatch, the AAAH 100 sets "previous FA-NAI" in 
the AMA message, and transmits this message. 
The "previous FA-NAI" identifies the FA SOOp at this 
time. 

(8) The AAAF 400n sets a service profile in the ses- 
sion transaction, and transmits the service profile to 
the FA 500n by using the AMA message. 

(9) Upon receipt of the AMA message in whicli the 
"previous FA-NAI" is set, the FA SOOn adds the serv- 
ice profile to the service profile cache. Then, the FA 
SOOn identifies the FA SOOp based on the "previous 
FA-NAI", and transmits to the FA SOOp the binding 
update In which the RO authentication notified by 
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the AMA message and the service profile are set. 

(1 0) The FA SOOp.deletes the visitor list of the mobile 
node 600, and generates a binding cache at the sa- 
metlme. Then, the FA 500p replaces the service 
profile stored in the service profile cache with the 
service profile notified by the binding update, and 
links the service profile with the binding cache. The 
FA 500p then returns a binding acknowledge mes- 
sage to the mobile node 600. 

(11) The FA 500n returns a registration reply mes- 
sage to the mobile node 600. The service profile 
and the biding cache of the FA 500p are deleted at 
the expiration of the lifetime of the cache. The serv- 
ice profile cache and the session transaction of the 
AAAF 400p are deleted upon session timeout. 

7B. Case where an AAAF specifies an HA 

[0134] Described in the following embodiment are (1 ) 
the sequence at the time of initial registration, (2) the 
sequence in the case where a mobile node moves from 
the communication area of one FA within a certain AAAF 
to that of another FA, and (3) the sequence in the case 
where a mobile node moves from the communication 
area of an FA within one AAAF to that of an FA within 
another AAAF. 

7B(i) Sequence at the time of initial registration 

[0135] Fig. 40 shows the sequence for distributing 
service profiles. In this sequence, the process from 
when the mobile node 600 transmits a registration re- 
quest message till when the AAAH 100 generates a 
service profile is the same as that in the case where the 
AAAH 100 specifies the HA (see the above described 
7A(1)). Explanation of the sequence for that portion Is 
therefore omitted here. 

(1) The AAAH 100 attaches a destination service 
profile (MN-HAdest), a source service profile (MN- 
HAsrc), a destination service profile (MN-FAdest), 
and a source service profile (MN-FAsrc) to an AMA 
(AA-Mobile-N ode-Answer) message, and transmits 
this message to the AAAF 400. 

(2) The AAAF 400 holds the notified service profiles 
by linking with the session transaction in order for 
the hand-off process within the same domain . 

(3) The AAAF 400 attaches the destination service 
profile (MN-HAdest) and the source service profile 
(MN-HAsrc) to an HAR (Home-Agent-M IP-Re- 
quest) message, and transmits this message to the 
HA 200. 

(4) The HA 200 generates a DIAMETER session 
transaction, and adds the notified service profiles to 
its own service profile cache. Additionally, the HA 
200 generates mobility binding based on the infor- 
mation of the registration request notified by the 
HAR message. Furthemnore, the HA 200 sets the 



link infomnation for an entry of the generated mobil- 
ity binding as a control information identifier of the 
destination service profile (MN-HAdest). 

(5) The AAAF 400 attaches the destination service 
5 profile (MN-FAdest) and the source service profile 

(MN-FAsrc) to the AMA message, and transmits this 
message to the FA 500. 

(6) The FA 500 adds the notified service profiles to 
Its service prof lie cache. At this time, the destination 

10 service profile (MN-FAdest) and the source service 
profile (MN-FAsrc) are respectively added to the 
destination SPC (ASPCdst) and the source SPC 
(ASPCsrc) of the AAA-notified SPC. Furthennore, 
the FA 500 sets the information (the home address 
15 and the HA address) notified by the AMA message 
In the visitor list, and specifies this list as a link des- 
tination of the destination service profile (MN- 
FAdest). 

(7) Upon termination of the generation of the service 
20 profile cache and the process for the AMA mes- 
sage, the FA, 500 returns a registration reply mes- 
sage to the mobile node 600. 

[0136] With the above described sequence, the serv- 
es ice profiles are respectively set in the service profile 
caches of the HA 200 and the FA 500. Thereafter, the 
packet transmitted from the mobile node 600 to the cor- 
respondent node CN 700, and the packet transmitted 
from the correspondent node CN 700 to the mobile node 
30 600 are processed according to these service profiles. 
The operations performed when a data packet Is proc- 
essed by referencing the service profile cache are the 
same as those in the case where the AAAH 100 speci- 
fies the HA (see the above described 7A(1)). According- 
35 ly, explanation of the sequence forthat portion is omitted 
here. 

7B{2) Sequence in the case where a mobile node moves 
from the communication area of one FA within a certain 
40 AAAF to that of another FA 

[01 37] This sequence is the same as that In the case 
where the AAAH 1 00 specifies the HA (see the above 
described 7A(2)). Its explanation Is therefore omitted 
45 here. 

7B(3) Sequence in the case where a mobile node moves 
from the communication area of an FA within one AAAF 
to that of an FA within another AAAF 

50 

[0138] Fig. 41 shows the sequence for distributing 
service profiles. Illustrated here is the case where the 
mobile node 600 moves from the communication area 
of an FA 500p subordinate to an AAAF 400p to that of 
55 an FA 500n subordinate to an AAAF 400n, in a similar 
manner in the example shown in Fig. 39. In this se- 
quence, the process from when. the mobile node 600 
receives an agent advertisement from the FA 500n till 
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when the AAAH 1 00 generates a transaction is tlie same 
as that in the case where the AAAH 100 specifies the 
HA 20 (seethe above described 7A(3)). its explanation 
is therefore omitted here. 

(1 ) if the address assigned to the HA within the ses- 
sion transaction is "0000" or "FFFF" when being ref- 
erenced, an AlVIR message is transmitted to the 
AAAF (namely, the AAAF 400p) that has specified 
the HA 200. 

(2) The AAAF 400p transmits an HAR message to 
the HA 200. 

(3) -(4) The HA 200 updates mobility binding accord- 
ing to the HAR message, and returns an HAA mes- 
sage to the AAAF 400p. 

(5) The AAAH 100 malces a comparison between 
the AAAF (AAAF 400n) which has transmitted the 
AMR message and that within the session transac- 
tion. If they mismatch, the AAAH 100 transmits to 
the AAAF 400n the AMA messiage in which "previ- 
ous FA-NAI" is set. A service profile is attached to 
this AMA message. 

(6) The AAAF 400n forwards the AMA message to 
the FA 500n. In this way, the service profile is dis- 
tributed to the FA soon. 

(7) -(8) Upon receipt of the AMA message in which 
the "previous FA-NAI" is set, the FA SOOn adds the 
service profile, which is attached to the message, 
to its service profile cache. Furthermore, the FA 
SOOn identifies the FA SOOp based on the "previous 
FA-NAI" set in the above described message. The 
FA SOOn then transmits to the FA SOOp the binding 
update where the RO authentication notified by the 
AMA message and the service profile are set. 
(9)-(10) The FA SOOp deletes the visitor list of the 
mobile node 600, and generates a binding cache at 
the same time. Then, the FA SOOp replaces the cur- 
rent service profile with the service profile notified 
by the binding update, and links the service profile 
with the binding cache. The FA SOOp then returns a 
binding acknowledge message to the mobile node 
600. 

(11) The FA SOOn returns a registration reply mes- 
sage to the mobile node 600. The service profile 
and the binding cache of the FA SOOp are deleted 
at the expiration of the cache. The service cache 
and the session transaction of the AAAF 400p are 
deleted upon session timeout. 

7C. Flowchart of each entity 

[01 39] Fig. 42 Is a flowchart explaining the process of 
the AAAH 1 00. This process is performed, for example, 
upon receipt of a DIAMETER protocol packet. 
[0140] In step S1, the message type of a received 
packet is detected. If the message type is an AMR mes- 
sage, the process proceeds to step S2. If the message 
type is either an AMA or an HAA message, the process 
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proceeds to step SB. If the message type is an SFR mes- 
sage, the process proceeds to step S13. In step S2. it 
is detected whether or not a session transaction has al- 
ready been generated. If the session transaction has al- 
5 ready been generated, the process proceeds to step S9. 
If the session transaction has not been generated yet, 
it Is generated In step S3. 

[0141] In step S4, a service control database is 
searched by using the NAI set in the AMR message as 

10 a key, and a service profile is generated based on the 
result of the search. In step SS, the generated service 
profile is set in the session transaction. 
[0142] In step S6, it is detected whether or not the 
AAAH must specify an HA. Which of the. AAAH and an 

IS AAAF specifies an HA may be predetermined or 
changed dynamically. If the AAAH must specify an HA, 
the HAR message to which the service profile Is at- 
tached is transmitted to the HA in step S7. If the AAAH 
does not need to specify an HA, the AMA message to 

^0 which the service profile is attached is transmitted to the 
AAAF in step S8. 

[0143] In step S9, it is detected whether or not the 
AAAF has been changed. If the AAAF has been 
changed, the process proceeds to step SI 0. If the AAAF 
25 has not been changed , the process proceeds to step S8 
where an AMA message is transmitted. In step Sio; it 
is detected whether or not an HA has already been spec- 
ified. If the HA has already been specified, an HAR mes- 
sage is transmitted to the HA in step 811 . If the HA has 
30 not been specified yet, an AMR message is transmitted 
to the AAAF that previously accommodated the mobile 
node. 

[0144] In step 813, an SFA message is returned to 
the source of the SFR message. In step 814, a session 
transaction is released. 

[01 45] The operations of the AAAH are explained be- 
low as specific examples. 

(1 ) Procedure for registering an initial location in the 
case where the AAAF specifies an HA (see Fig. 40) 
This process Is performed, for example, when 
a registration request message Is transmitted from 
a mobile node to an FA, and an authentication re- 
quest message is transmitted from the FA to an 
AAAH via the AAAF 

81 :The process proceeds to step 82, since an 
AMR (AA-Mobile-Node-Request) message is 
received from the AAAF. 
82: A session transaction is searched by using 
the NAI of the mobile node as a key, which Is 
notified by the AMR message. Note that a ses- 
sion transaction has not been generated yet at 
the time of initial location registration. There- 
fore, the process proceeds to step S3. 
S3: A session transaction is generated. 
84: A service control database 300 Is searched 
by using the NAI of the mobile node as a key, 
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and a service profiie is generated based on the 
infomiation resultant from the search and the 
policy for generating a service profile. In this 
way, the service profile shown in Rg. 12 is gen- 
erated. The policy for generating a service pro- 5 
file and a specific configuration method are not 
particularly limited. However, since some ex- 
amples are provided above, they are not cited 
here. 

S5: The service profile is set in the session io 
transaction. 

S6: Which of the AAH and the AAAF specifies 
the HA is detemilned If either "0000" or "FFFP 
Is set as the HA address of the AMR message. 
A detemninatlon condition is assumed to be giv- is 
en by a provider. Here, it is assumed that the 
AAAF specifies the HA. The process then pro- 
ceeds to step S8. 

SB: The sen/ice profile generated in step S4 is 
attached to an AlVIA message, and the mes- 20 
sage is transmitted to the AAAF. 

(2) Procedure for registering an initial location In the 
case where an AAAH specifies an HA (see Fig. 26) 

25 

S1 to S5: The same as the above described 
< case (1). S6: The process proceeds to step S7 
: - based on the assumption that the AAAH spec- 
" • ifies the HA. 

S7: The HA Is specified, and the HAR message 50 

to which a service profile is attached is trans- 

mitted to the specified HA, 

(3) Procedure for registering the location of a mobile 
node which moves between IS Ps In the case where 35 
an AAAH specifies an HA 

This process is performed, for example, when 
a certain mobile node moves from the communica- 
tion area of one FA subordinate to one AAAF to that 
of another FA subordinate to another AAAF ^ 

S1 : The process proceeds to step S2, since an 
AI\^R message Is received from the AAAF. 
S2: A session transaction (see Fig. 14) is 
searched by using the NAI of the mobile node ^5 
as a key, which Is notified by the AMR message. 
Since an authentication process has been ter- 
minated here, a session transaction exists. Ac- 
cordingly, the process proceeds to step S9. 
S9: Whether or not the- AAAF has been so 
changed Is detected by making a comparison 
between the address of the current AAAF in the 
session transaction obtained In step 82 and the 
source address of the received AMR message. 
Because the mobile node is assumed to move ss 
between ISPs here, the AAAF has been 
changed. Therefore, the process proceeds to 
step 81 6. 



810: Whether or not the HA has already been 
specified is detected by the AAAH itself by ref- 
erencing the HA address of the session trans- 
action. Here, It is assumed that the HA has al- 
ready been specified by the AAAH itseff . if the 
HA has not been specified by the AAAH, for ex- 
ample, either "0000" or "FFFF" Is supposed to 
be set as the HA address. 
811 : An HAR message is transmitted to the al- 
ready specified HA. 

(4) Procedure for registering the location of a mobile 
node which moves between ISPs In the case where 
an AAAF specifies an HA (see Fig. 41 ) 

81 to 89: The same as the above described 
case (3) SIC: The process proceeds to step 
812, since the HA Is specified by the AAAF. If 
the HA is specified by the AAAF, for example, 
"0000" or "FFFF" is set as the HA address. 
SI 2: A session transaction (tlie address of the 
AAAF which has specified the HA In Fig. 14) Is 
referenced, and an AM R message is fonwarded 
to the AAAF which has specified the HA. 

(5) Procedure for updating location registration at 
the expiration of a session timer 

This process is performed, for example, at the 
expiration of a session timer while a mobile node 
stays in the communication area of a certain FA. 
When the session timer expires, an AMR message 
for updating the location registration is transmitted 
to an AAAH, 

SI to 82: The same as the above described 
case (3) 

89: Since there Is no location registration due 
to the move of the mobile node, an AAAF has 
not been changed. Accordingly, the process 
proceeds to step S8, 

88: Attaching the service profiie generated in 
step 84 to an AMA message, and transmitting 
the message to the AAAF. 

(6) Procedure upon termination of the location reg- 
istration to an HA 

This process is performed upon receipt of an 
HAA message from an HA, or an AMA message 
from an AAAF which has specified the HA. Note that 
the AAAH receives the HAA message from the HA 
when transmitting an HAR message to the HA in 
step 811 . Furthennore, the AAAH receives an AMA 
message from a previous AAAF when transmitting 
an AMR message to the previous AAAF in step S12. 

S1 : The process proceeds to step SB upon re- 
ceipt of the HAA or the AMA message. 
88: The service profile generated In step 84 is 
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attached to the AMA message, and the mes- 
sage is transmitted to the AAAF. Upon receipt 
of the AMA message from the previous AAAF, 
the AMA message to which the service profile 
is attached Is transmitted to a new AAAF. 5 

(7) Procedure for releasing a session 

This process is perfonned upon receipt of an 
SFR (Session Free Request) message. Remember 
that the SFR message is generated by a server io 
which does not directly relate to the present inven- 
tion. The SFR message is generated, for example, 
when an accounting server receives an accounting 
stop message. 

IS 

SI : The process proceeds to step SI 3 upon re- 
ceipt of the SFR message. 
S13: An SFA (Session Free Answer) message 
is returned to the server that has transmitted 
the SFR message. 20 
S14: Releasing the session transaction. 

[0146] Figs. 43 and 44 are flowcharts explaining the 
process of the AAAF 400. This process is performed, 
for example, upon receipt of a DIAMETER protocol 25 
packet. 

[0147] In step S21, the message type of a received 
packet is detected. If the message type is an AMR mes- 
sage, the process proceeds to step S22. If the message 
type Is an AMA message, the process proceeds to step so 
S41 . If the message type Is an HAA message, the proc* 
ess proceeds to step S51 . Or, if the message type is an 
SFR message, the process proceeds to step S61. In 
step S22, It is detected whether or not "previous FA-N AI" 
is notified by the AMR message. If the "previous FA-NA!" 55 
is notified, the process proceeds to step S31 . If the "pre- 
vious FA-NAI" Is not notified, the process proceeds to 
step S23. 

[0148] In step S23, a session transaction is searched 
by using the NAI set in the AMR message as a key. In 40 
step S24, it is detected whether or not a session trans- 
action has already been generated. If the session trans- 
action has not been generated yet, it is generated in step 
S26, 

[0149] In step S26, it Is detected whether or not an HA 45 
has already been specified by the AAAF Itself. If the HA 
has already been specified, an HAR message Is trans- 
mitted to the HA In step S27. If the HA has not been 
specified yet, an AAAH is identified based on the NAI 
set In the AMR message in step S28, and the AMR mes- so 
sage is forwarded to the Identified AAAH. Then, "HA is 
being requested" Is set as an operation state in step 
S29. 

[0150] In step S31, the session transaction is 
searched by using security infonnation. In step S32, a 55 
service profile Is attached to the AMA message, which 
is then transmitted to the FA. In step S33, "waiting to be 
processed" is set as an operation state. 



[01 51 ] In step S41 , the service profile is set in the ses- 
sion transaction. In step S42. it is detected whether or 
not the HA has already been specified by the AAAF it- 
self. If the HA has not been specified yet, it is specified, 
and at the same time, the HAR message to which the 
service profile is attached is transmitted to the specified 
HA In step 843. Then, "AMA is being processed" is set 
as the operation state in step S44. On the other hand, 
if the HA has already been specified^ the process pro- 
ceeds to step 833, after the AMA messa[ge Is fonvarded 
to the FA in step S45. 

[0152] In step S51 , the operation state is examined. 
If "HA is being requested" is set as the operation state, 
the process proceeds to step S33, after transmitting the 
AMA message to the AAAH in step 852. On the other 
hand, if the "AMA Is being processed" is set as the op- 
eration state, the process proceeds to step 833 after for- 
warding the AMA message to the FA In step S53. 
[01 53] In step S61 , an SFA message is transmitted to 
the AAAH. Then, the session transaction is released In 
step 862. 

[01 54] The operations of the AAAF are described be- 
low as specific examples. 

(1) Procedure for registering an Initial location (see 
Figs. 26 and 40) 

821 : The process proceeds to step 822, since 
an AMR message is received from the FA. 
822: "Previous FA-NAI AVP" is not included In 
the AMR message, since this is initial location 
registration. Accordingly, the process proceeds 
to step S23. 

823: A session transaction is searched by us- 
ing the NAI notified by the AMR message as a 
key, 

824: The session transaction , which is a search 
target in step S23, does not exist in the AAAF, 
since this is the initial location registration. Ac- 
cordingly, the process proceeds to step 825. 
825: A session transaction Is generated. 
826: An HA has not been specified yet at the 
time of the initial location registration. Accord- 
ingly, the process proceeds to step 828. 
VVhether or not the HA has been specified Is 
detected according to the HA address In the 
session transaction. For example, "0000" Is set 
as the HA address immediately after a session 
transaction is generated. 
828 : The AAAH of the ISP to which the mobile 
node belongs is identified based on the domain 
portion of the NAI of the mobile node, which is 
set in the AMR message, and the AMR mes- 
sage is forwarded to the identified AAAH. 829: 
"HA Is being requested" Is set as an operation 
state. 

(2) Procedure for registering the location of a mobile 
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node which moves between ISPs in the case where 
the AAAF specifies an HA (see Fig. 41 ) 

Described here are the operations of the AAAF 
(equivalent to the AAAF400p shown In Fig. 41 . and 
referred to as a "previous AAAF" in this case) to s 
which the FA accommodating the mobile node be- 
longs prior to the move of the mobile node. 

S21 : The process proceeds to step S22, since 
the previous AAAF receives the AMR message 'fo 
from the AAAH. 

S22: "previous FA-NAl AVP" is not included in 
the AMR message, since the mobile node 
moves to a different domain Accordingly, the 
process proceeds to step S23. 
S23: A session transaction Is searched by us- 
ing the NAI notified by the AMR message as a 
key. 

S24: Such a session transaction exists in the 
previous AAAR Accordingly, the process skips 

step S25. 

S26: The address of the HA set by the AAAF 
itself is set as the HA address in the session 
transaction. Accordingly, the process proceeds 
to step S27. 

S27: An HAR (Home- Agent-M IP-Request) 
message is transmitted to the HA. 
829: "HA is being requested" is set as an oper- 
' ation state. 

30 

(3) Procedure for registering the location of a mobile 
node which moves within an ISP (see Fig. 38) 

'I- Here, assume that the FA which previously ac- 
co'nlitibdated the mobile node prior to its move is 
refen-ed to as a "previous FA", whereas the FA 35 
which accommodates the mobile node after its 
move is referred to as a "new FA". 

821 : The process proceeds to step S22, since 
the AAAF receives an AMR message from the 40 
new FA. 

822: Since the mobile node moves within a 
same domain, the mobile node sets "previous 
FA-NAl extension" of a registration request 
message, and FA sets "previous FA-NAI AVP" 
of the AMR message. 

S31 : A session transaction is searched by us- 
ing security infonnation (MN-FA-SPI). 
832: The service profile and the security infor- 
mation, which are set in the session transac- so 
tion, are attached to an AMA (AA- Mobile-Node- 
Answer) message, which is then transmitted to 
the new FA. 

833: "waiting to be processed" is set as an op- 
eration state. ss 

(4) Procedure for registering a location in the case 
where the AAAF specifies an HA (see Fig. 40) 



821: The AAAF receives an AMA message 
from the AAAH as a reply to the AMR messaged 
Accordingly, the process proceeds to step S41 . 
S41 : A session transaction Is identified by ref- 
erencing a DIAMETER identifier field. The sen/- 
ice profile notified by the AMA message is set 
in the identified session transaction. 

542. Here, assume that the HA has not been, 
specified yet, and the process proceeds to step 

543. If the HA has been specified by the AAAF 
itself: for example, "0000" or "FFFF" is set as 
the HA address set in the AMA message. 
843: The HA is specified, and the HAR (Home- 
Agent-M IP- Request) message to which the 
service profile is attached is transmitted to the 
specified HA. 

S44: "AMA is being processed" is as an oper- 
ation state. 

(5) Procedure for registering a location in the case 
where the AAAH specifies an HA (see Figs. 26 and 
41) 

Here, the operations of, for example, the AAAF 
400 shown in Fig. 26 or the AAAF 400n shown in 
Fig. 41 are explained. 

821 and 841 : The same as the above de- 
scribed (4). 

842: Here, assume that the HA has already 
been specified by the AAAF itself, and the proc- 
ess therefore proceeds to step 845. 
845. The FA is identified based on "current FA- 
NAl" in a session transaction, and an AMA 
message is fonwarded to the identified FA. 
833. "waiting to he processed" Is set as an op- 
eration state. 

(6) Procedure for registering the location of a mobile 
node which moves between ISPs in the case where 
the AAAF specifies the HA (see Fig. 41 ) 

Here, the operations of, for example, the AAAF 
400p shown in Fig. 41 are described. 

821: The process proceeds to step S51 upon 
receipt of an HAA (Home-Agent-M IP-Answer) 
message from the HA as a reply to an HAR 

message. 

851: A session transaction is identified based 
on a session ID, and the operation state of the 
session transaction is examined. Here, assume 
that "HA is being requested" is set as the oper- 
ation state. The process therefore proceeds to 
step 852. 

852: The AAAH is identified from the session 
transaction, and an AMA message is transmit- 
ted to the AAAH. 

S33: "watting to be processed" is set as the op- 
eration state. 
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(7) Procedure for making a registration reply In the 
case where the AAAF specifies an HA 

S21 : The process proceeds to step S51 upon 
receipt of an HAA message from the HA as a 
reply to an HAR message. 
S51 . A session transaction is identified based 
on a session (D, and the operation state of the 
Identified transaction is examined. If the AAAF 
specifies the HA, "AMA is being processed" is 
set as the operation state. This is because 
steps S43 and S44 should have been execut- 
ed. Accordingly, the process proceeds to step 
S53. 

S53: The FA is Identified from the session trans- 
action, and the AM A message to which a serv- 
ice profile Is attached is transmitted to the iden- 
tified FA. 

S33: "waiting to be processed" is set as the op- 
eration btate. 

(8) Procedure for releasing a session 

S21 : The process proceeds to step S61 upon 
receipt of an SFR message from the AAAH. 
Note that the SFR message is generated due 
to causes such as an accounting process stop, 
a fault, etc. 

S61 : A session transaction is identified based 
on a session ID, and an SFA message is trans- 
mitted to the AAAH identified from the transac- 
tion. 

S62: The session transaction is released. 

[01 55] Fig. 45 is a flowchart explaining the operations 
of the HA 200, FA 500, or the CN 700. This process is 
performed upon receipt of a packet. 
[0156] In step S71 , the IP header infomnation of a re- 
ceived packet Is extracted. The IP header is the one 
shown In Fig. 62A. Remember that this process is per- 
formed by the packet controlling unit 201 . In step S72, 
the destination address and the port number In the 
header information are referenced, and whether the re- 
ceived packet is either a data or a protocol packet is 
detected. Steps S73 through 875 are executed If a pro- 
tocol packet Is received, and steps 876 through 879 are 
executed if a data packet is received. 



DIAMETER protocol, the service profile cache 
of the Individual service controlling unit 203 is 
updated with the distributed service profile. 
875: The table of the service-independent unit 
s 204 Is generated according to a mobile I P mes- 

sage, and the Information required for that table 
is set. Additionally, a necessary message is 
transmitted according to the mobile IP. 

10 (2) Operations performed when a data packet is re- 
ceived 876: The service profile cache is searched 
by using as a key the header Infonnation extracted 
by the packet controlling unit 201 according to the 
policy set in the search policy management table. 

IS Then, the received packet is edited according to 
"routing/packet editing Information" in the extracted 
sen/ice profile. This processes performed by the in- 
dividual service controlling unit 203. 

^0 S77: If a predetemnined function of the service- 

independent unit 204 Is specified by the service 
profile extracted in step 876, control is given to 
the service-independent unit 204 and the proc- 
ess proceeds to step 878. 

25 878: The service-Independent unit 204 deter- 

mines the editing method and the forwarding 
destination of the packet by referencing the 
control table specified by the service profile. 
879: After the packet is edited depending on 

30 need, it is forwarded. 

7D. Management of service profiles 

[01 57] With the system according to this embodiment, 
35 each user can select a service that he or she desires to 
use. Accordingly, a variety of users exist: one user re- 
quests various value-added sen/ices, another user re- 
quests no value-added services, and still another user 
requests only a particular fundamental value-added 
40 service. The information about the service requested by 
each user Is stored in the service control database 300 
for each user. 

[0158] A method efficiently using a service profile is 
explained below by assuming the case where no value- 
4s added services are requested, and the case where only 
a particular fundamental value-added sen^lce Is re- 
quested. 



(1 ) Operations perfonned when a protocol packet 
is receh^ed 



so 



(1 ) IVIanagement of a service profile for the user who 
requests no value-added services 



873: Upon receipt of a protocol process request 
from the packet controlling unit 201 , the proto- 
col controlling unit 202 analyzes the port 
number of the UDP header, and detects wheth- 
er a requested process is either a mobile IP or 
a DIAMETER process. 

S74: When a service profile is distributed by the 



[0159] An HA and an FA respectively generate the 
service profiles shown in Figs. 46 and 47 at the time of 
an initial configuration. A minimum of the information re- 
55 quired to support the mobile I P Is set in each of the serv- 
ice profiles. 

[0160] An AAAH does not generate a service profile 
for the user who requests no value-added services 
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when the registration of his or her mobile node is re- 
quested. Whether ornot the user of the mobile node that 
transmits the registration request message requests a 
value-added service may be determined, for example, 
by searching a service control database with the use of 
the NAi set in the Al\/IR message transmitted upon a reg- 
istration request, as a Icey. "not generating a service pro- 
file upon request of mobile node registration" is one ex- 
ample of a service profile configuration policy in step S4 
of Fig. 42. 

[0161] Accordingly, asen/ice profile foravalue-added 
service Is not newly distributed from the AAAH to the HA 
and the FA. Furthemnore, no settings are made by the 
HA and the FA in the AAA-notlfied SPC in the sen^ice 
profile caches forthis user, as shown in Figs. 46 and 47. 
[01621 When the data packet addressed to the con-e- 
spondent node CN is transmitted from the mobile node 
In the above described configuration, it Is received by 
the FA which accommodates the mobile node. Upon re- 
ceipt of this data packet, the FA searches the service 
profile cache shown in Fig. 47. Here, the "mobile node" 
and the "correspondent node CN" are set as the source 
address and the destination address of this data packet 
respectively. Accordingly, If the service profile cache 
shown In Fig. 47 Is searched according to the search 
policy shown in Fig. 20, a default service profile (NDSP) 
is to be referenced. In the default service profile (NDSP), 
a routing table that a router originally manages is des- 
ginated as a table to be accessed- The received data 
packet is therefore forwarded to the correspondent node 
CN according to the routing table. 
[01 63] Or, when the data packet addressed to the mo- 
bile node is transmitted from the correspondent node 
CN,' it'is transferred to the HA, which is the home agent 
of the mobile node. Upon receipt of this data packet, the 
HA searches the service profile cache shown in Fig. 46. 
Here, the "correspondent node" and the "mobile node" 
are set as the source address and the destination ad- 
dress of the data packet respectively Accordingly, If the 
service profile cache shown In Fig. 46 is searched ac- 
cording to the search policy shown in Fig. 20, a destina- 
tion service profile (NSPCdst) is tobe referenced. Be- 
cause a mobility binding is designated by the destination 
service profile (NSPCdst) as a table to be accessed, the 
received data packet is fora^arded to the FA according 
to the mobility binding. At this time, this packet Is encap- 
sulated. 

[0164] Upon receipt of the encapsulated packet, the 
FA searches the service profile shown in Fig. 47. Here, 
the "HA" and the "FA (care-of address)" are set as the 
source address and the destination address of this data 
packet, respectively. Accordingly, if the service profile 
cache shown in Fig. 47 Is searched according to the 
search policy shown in Fig. 20, the destination service 
profile is to be referenced. As a result, this data packet 
is decapsulated. Furthermore, since the service profile 
cache is designated as infomriation to be accessed by 
the destination service profile (NSPCdst), it is again 



searched by using the header Information of the decap- 
sulated packet as a key. 

[0165] The "HA" and the "mobile node" are respec- 
tively set as the source address and the destination ad- 

5 dress of the decapsulated data packet. Therefore, If the 
service profile cache shown in Fig. 47 is searched ac- 
cording to the search policy shown in Fig. 20, the des- 
tination default service profile (NDSPdst) Is to be refer- 
enced. Accordingly, the decapsulated packet is fonward- 

10 ed to the mobile node according to the visitor list. 

(2) Management of a service profile for a user who 
requests only a particular fundamental value-added 
service 

15 

[0166] Many users are expected to use the funda- 
mental value-added service set (such as the quality 
guarantee service shown in Fig. 7) provided by an In- 
ternet service provider unchanged, although some us- 

20 ers desire a more fine-grained service. In such a situa- 
tion, a service profile pattern converges on a numerical 
pattern. Therefore, service profile setting for each user 
may result in a waste of resources. 
[0167] Considered as a method overcoming this prob- 
es lem is a method making a correspondence between a 
service class to be provided and the IP address as- 
signed by an AAA or an HA beforehand. For example, 
an Internet service provider predetemiines the IP ad- 
dress range assigned to a mobile node for each service 

30 class, and notifies other providers of the predetermined 
range. The provider which receives this notification sets 
necessary Infomnation in the service profile caches of 
each HA and FA according to the notification. 
[01 68] The AAAH detenmines whether or not the user 

35 of a mobile node requests only the fundamental value- 
added service set when assigning an IP address to the 
mobile node, for example, in a dial-up procedure. 
Whether or not each user requests only the fundamental 
value-added service set, and which service class is se- 

40 lected If the fundamental set is requested can be detect- 
ed by referencing the service control database 300. If 
the user requests only the fundamental value-added 
service set, the AAAH assigns to the mobile node the 
IP address corresponding to the service class selected 

45 by the user. At this time, the AAAH does not distribute 
a service profile to the HA and the FA. Note that "not 
generating a service profile when an IP address is as- 
signed" is one example of the service profile configura- 
tion policy in step 84 of Fig. 42. 

50 [0169] The HA and FA provide the fundamental value- 
added servbe set by referencing the service profile 
cache. As a result, the capacity of the sen/ice profile 
cache is reduced. Furthermore, it is sufficient to exam- 
ine only the upper portion of an IP address when the 

55 service profile cache is searched, thereby speeding up 
the search. 

[0170] Fig. 48 shows an example of the method pre- 
detemilning IP address ranges used for service classes. 
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In this example, "172.27.180.*", "172,27.185/". and 
"172.27.190.*" are respectively assigned to service 
classes A, B, and C as the IP address ranges. Here, 
is a wildcard. I n the service profiles distributed to the HA 
and the FA, for Instance, "1 72.27. 1 80.*" Is set as target s 
packet control Infomiation, and the information for pro- 
viding the service class A is set as a routing/packet ed- 
iting method and individual control info mnat Ion. Accord- 
-ingly, upon receipt of the packet having the upper ad- 
dress portion "172.27.180" as a source address or a io 
destination aiddress, the HA and the FA perfomn the 
process for supporting the service class A for this pack- 
et. 

7E. Route optimization is 

[01 71] The packet addressed from the correspondent 
node CN 700 to the mobile node 600 Is once transferred 
to the HA 200 according to the address of the mobile 
node 600 in norrhal cases. The packet Is then transmit- 20 
ted to the mobile node 600 after being forwarded from 
the HA 200 to the FA 500. 

[0172] A route optimization process is a procedure for 
directly transferring the packet addressed to the mobile 
node 600 to the FA 500 not via the HA 200 in the above 55 
described case. Distribution of a service profile, which 
is required to Implement the above described optimiza- 
tion, is explained below by referring to Fig. 49. 

(1 )The HA 200 receives the data packet addressed 30 
to the mobile node 600 from the correspondent 
node CN 700. In this case, this packet hits the serv- 
ice profile In which the address of the mobile node 
600 is set as the filter information for the destination 
address. Accordingly, the HA 200 edits and encap- 3$ 
sulates the packet according to the infomriation of 
the hit service profile, and transmits the encapsu- 
lated packet to the FA 500 that accommodates the 
mobile node 600. The FA 500 decapsulates the re- 
ceived packet, and forwads the decapsulated pack- 40 
et to the mobile node 600. 

(2) The HA 200 recognizes that the correspondent 
node CN 700 does not have a service profile cache 
and a binding cache, by receiving the data packet 
transmitted from the correspondent node CN 700. 45 
Then, the HA 200 attaches the sen/ice profile used 

in the above described (1 ) to a binding update mes- 
sage, and transmits this message to the corre- 
spondent node CN 700. 

(3) An "A (answer) bit" of the binding update mes- so 
sage is used to request a binding acknowledge 
message, Furthennore, "route optimization authen- 
tication extension (RO authentication)" is used 
when the correspondent node CN 700 authenti- 
cates a route optimization request. Note that a serv- ss 
ice profile is an extension for service control. 

(4) Upon recelptof the binding update message, the 
correspondent node CN 700 generates a service 



profile and biding cache. If the "A bit" is set, the 
con-espondent node CN 700 returns a binding ac- 
knowledge message to the HA 200. The lifetime of 
the binding cache is a current remaining time of the 
lifetime set by the registration request message. 

The binding cache is configured, for Instance, 
as shown In Fig. 23. In the above described exam- 
ple, the "correspondent node CN 700", the "mobile 
node 600", and the "FA 500" are respectively set as 
a source address, a destination address, and a 
care-of address. In this case, the "address of the 
mobile node 600" is set as the destination address 
of target packet control information, and the binding 
cache is specified as a table to be accessed in the 
sen/lce profile. 

(5) The correspondent node CN 700 references the 
service profile generated in the above described (4) 
when transmitting the packet addressed to the mo- 
bile node 600. Since the mobile node 600 is regis- 
tered to the destinatioh service profile (ASPCdst) in 
the service profile notified from the AAA in this case, 
the binding cache is referenced. As a result, the 
packet is encapsulated, and tunneled to the FA 500 
that Is specified as the care-of address. At this time, . 
necessary editing Is performed for the encapsulat- 
ed packet according to the service profile. 

[01 73] As described above, a service profile is distrib- 
uted from the HA to the correspondent node CN, so that 
the distribution of the service profile with route optimi- 
zation can be easily implemented. If the route optimiza- 
tion process Is not required, there is no need to arrange 
the individual service controlling unit 203 and the serv- 
ice-Independent unit 204 in the correspondent node CN. 

8. AN YCAST service 

[01 74] There may be cases where a single user pos- 
sesses a plurality of terminals, and desires to use an 
arbitrary one of them according to the circumstances. 
Furthermore, in a system including a plurality of servers, 
the configuration where an access to this system is di- 
vided to an arbitrary server in orderto distribute the load 
on each of the servers, is known. 
[01 75] In the former case, one virtual address shared 
by the plurality of temninals Is used. When a packet is 
transmitted to the virtual address, it is forwarded to a 
predetermined one of the temiinals . In the latter case, 
one virtual address shared by the plurality of servers is 
used. When an access is made to this address, a packet 
Is transmitted to a predetermined one of the servers. 
[01 76] In this embodiment, the above described serv- 
ice is defined to be called an "ANYCAST service". Ad- 
ditionally, the virtual address in the above described ex- 
ample Is defined to be called an "ANYCAST address". 
[0177] Fig, 50 is a schematic diagram explaining an 
ANYCAST service. In this figure, an ANYCAST address 
(IP#A1) is assigned to a plurality of servers #1 through 
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#4. Here, an ANYCAST address is a subnet of an ad- 
dress proxy server (AP) 800 to be described later. Ad- 
ditionally, actual IP addresses of the servers #1 through 
#4 are respectively "IP#Hr through "IP#H4". The serv- 
ers #1 and #2 are accommodated by an FA 500 (#1), 5 
whereas the servers #3 and #4 are accommodated by 
an FA 500 (#2). 

[0178] The address proxy server 800 has fundamen- 
tally the same configuration as that of an HA. Note that, 
however, the address proxy server 800 transfers the io 
pacicet In which an ANYCAST address is set to one or 
a plurality of addresses con-esponding to the ANYCAST 
address. In the example shown In Fig. 50, upon receipt 
of the packet in which the ANYCAST address (IP#A1) 
is set, the address proxy server 800 transfers the packet ^5 
to one of the servers #1 through #4. To which of the serv- 
ers the packet is to be transferred is described In the 
service profile generated and distributed by an AAAH. 
[0179] An ANYCAST service is managed by the 
AAAH in the ANYCAST address management table 
shown In Fig. 13. This table stores one or more NAIs 
corresponding to an ANYCAST address, the home ad- 
dress of the ten-ninal identified by each NAI, and the 
state of the terminal identified by each NAI for each AN- 
YCAST address. The state of the terminal Is, for exam- ^5 
pie, an online, an offline, a pending, afaulty, a congested 
state, etc. In the example shown in Fig. 50, the IP ad- 
dresses (IP#H1 through IP#H4) of the servers #1 
through #4 and their states are set for the ANYCAST 
address (I P#A1). 

[0180] The AAAH generates a service profile for 
transferring the packet In which an ANYCAST address 
is set to one or a plurality of addresses corresponding 
to the ANYCAST address, and distributes the generated 
profile to the address proxy server 800. An example of 35 
the service profile distributed to the address proxy serv- 
er 800 is shown in Fig. 51. 

[0181] In "transfer destination address" in this service 
profile, one or a plurality of the IP addresses (IP#H1 
through I P#H4) of the servers #1 and #4 are set. Which 40 
of the addresses is to be set is determined according to 
the address selection policy in the profile shown in Fig. 
1 1 . The address selection policy is, for example, "select- 
ing a temninal in an online state", "not selecting a temil- 
nal in an offline, a pending, a faulty, or a congested 4s 
state", etc. When the above described service profile Is 
distributed, the address proxy server 800 transmits the 
packet to the destination specified by the service profile. 
If a plurality of destinations are specified by the service 
profile, the address proxy sender 800 can sequentially 
select the transfer destinations one by one, 
[0182] To the HA 200, the service profile shown in Fig. 
52 is distributed. In this service profile, mobility binding 
Is specified as a table to be accessed. In the mobility 
binding, the FA 500 (#1) is assigned to the IP addresses . 55 
of the servers #1 and #2 as shown in Fig. 50, whereas 
the FA 500 (#2) is assigned to the IP addresses of the 
servers #3 and #4. 



[01 83] To the FA 500, the service profile shown in Rg . 
53 is distributed. This service profile is generated for the 
temriinal that subscribes to an ANYCAST service. In this 
service profile, the ANYCAST table shown In Fig. 24 is 
specified as a table to be accessed. The ANYCAST ta- 
ble is obtained by setting an "ANYCAST address" and 
the "address of an address proxy server** In a nomnal 
visitor list. 

[0184] The FA 500 generates the service profile 
shown in Fig. 54, In this service profile, the information 
for providing the fundamental functions of the mobile IP 
are set.. Also the service profile shown in Fig. 55 Is dis- 
tributed to the FA 500. This service profile is generated 
for the terminal that does not subscribe to an ANYCAST 
service. 

[0185] When the packet in which an ANYCAST ad- 
dress is set Is transmitted from the terminal #1 in the 
above described system, It Is transferred to the address 
proxy server 800. The address proxy server 800 trans- 
fers this packet to a predetennined server according to. 
the service profile distributed from the AAAH, In this ex- 
ample, the IP address (IP#H2) of the server #2 is set in 
this packet. 

[01 86] This packet is transferred to the HA 200, which 
is the home agent of the server #2. The HA 200 transfers 
the packet to the FA 500 (#1) according to the mobility 
binding. This packet is doubly encapsulated. 
[0187] Upon receipt of this packet, the FA 500 (#1) 
calls the ANYCAST table by referencing the sen/ice pro- 
files shown in Figs. 54 and 53. The FA 500 (#1) then 
decapsulates the packet by detecting the link layer ad- 
dress of the server #2 from the IP address of the server 
#2 based on the ANYCAST table, and by recognizing 
the ANYCAST address and the address proxy server 
800. As a result, the decapsutated packet is delivered 
to the server #2. SImilariy, the packet transmitted from 
the temninal #2 is transfen-ed to the server #3. 
[0188] In this way. the address proxy server, HA, and 
FA execute the ANYCAST service according to the serv- 
ice profiles generated by the AAAH. At this time, the ter- 
minal that subscribes to the ANYCAST service is man- 
aged by the AAAH in a centralized manner. Accordingly, 
the packet in the ANYCAST service Is transferred to a 
suitable mobile node without fail. 
[0189] Figs. 56 and 67 exemplify the sequence for 
setting ANYCAST infonnatlon. This sequence is started 
when the mobile node 600 transmits a registration re- 
quest message to the FA 500. Remember that the AAAH 
100 includes an authentication server and an authoriza- 
tion server. 

(1) Upon receipt of the registration request mes- 
sage, the FA 500 generates a visitor list, arid trans- 
mits an AMR message at the same time. 

(2) The authentication server of the AAAH 1 00 that 
has received the AMR message extracts the au- 
thentication information of the user from the service 
control database 300. 
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(3) If the authentication is successfully made, serv- 
ice control is requested to the authorization server. 
The authorization server then reads the corre- 
sponding service profile from the service control da- 
tabase 300, and extracts an ANYCAST address. 5 

(4) The authorization server transmits an ANY- 
CAST registration request nnessage to the address 
proxy server 800. The service profile is attached to 
this message. 

(5) The address proxy server 800 specifies the HA io 
200 which serves as the home agent of the mobile 
node 600, and also specifies the home agent ad- 
dress of the mobile node at the same time. As a 
result, the service profile cache shown in Fig. 51 is 
generated. is 

(6) The address proxy server 800 notifies the au- 
thorization server of the address of the HA 200 and 
the home address of the mobile node 600 by using 
an ANYCAST registration reply message. 

(7) The authorization server generates the address 20 
management table shown in Fig. 13. Additionally, 

the authorization server generates the service pro- 
file corresponding to the mobile node 600 that has 
transmitted the registration request message. 

(8) The authorization server notifies the authentica- 
tion server of the generated service profile by using 
a service control reply message. 

(9) The registration request process is executed 
with a normal procedure. 

(1 0) Upon receipt of the AIVI A message, the FA 500 30 
generates an ANYCAST table (extended visitor list) 
based on the visitor list and the infonnation notified 

by the AMA message. The FA 500 then notifies the 
mobile node 600 of the ANYCAST address. 

35 

[01 90] Fig. 68 exemplifies the sequence for transfer- 
ring a packet by using an ANYCAST service . Each of 
the packets shown in Fig. 58 sequentially represents 
"source address", "destination address", and "payload" 
from the left side of the drawing sheet. The addresses 40 
indicated by arrows in this figure are those referenced 
in a routing process. 

[0191] Provided below is the sequence implemented 
when the correspondent node ON 700 that has received 
a data packet from the mobile node 600 returns the 45 
packet to the mobile node 600. It is assumed that the 
mobile node 600 is given an ANYCAST address with 
the above described process. 

(1 ) The correspondent node CN 700 transmits the so 
packet the destination of which is the ANYCAST ad- 
dress assigned to the mobile node 600. Here, the 
ANYCAST address is an address of the subnet of 

the address proxy server 800. Accordingly, this 
packet is fonwarded to the address proxy server ss 
800. 

(2) Upon receipt of the packet, the address proxy 
server 800 references the service profile con^e- 



spondlng to the ANYCAST address set in the pack- 
et, and selects one of the home addresses of the 
mobile node 600 from the service profile. A method 
selecting one of a plurality of home addresses Is not 
particulariy limited. However, by way of example, a 
home address Is sequentially selected. 

(3) The address proxy server 800 generates a sen/- 
ice profile to bind the selected home address of the 
mobile node 600 and the address of the corre- 
spondent node CN 700, and transmits the generat- 
ed service profile to the correspondent node CN 
700 by using a binding update message. The ad- 
dress notified by this message is not the care-of ad- 
dress (the address of the FA which accommodates 
the mobile node 600) of the mobile node 600, but 
the home address of the mobile node 600. 

(4) The address proxy server 800 encapsulates the 
packet received from the correspondent node CN 
700, and transmits the encapsulated packet to the 
home address selected in the above described (2). 
This packet is transferred to the HA 200 according 
to the home address of the mobile node 600. 

(5) Upon receipt of the encapsulated packet, the HA 
200 further encapsulates the packet. The HA 200 
then transmits the doubly encapsulated packet to 
the care-of address of the mobile node 600. In this 
way, the doubly encapsulated packet is transferred 
to the FA 500. 

(6) Upon receipt of the above described packet, the 
FA500 references the ANYCAST table orthe visitor 
list, and transmits the received packet to the mobile 
node 600. Specifically, the service profile cache is 
searched by using the address (care-of address) of 
the FA 500 as a key, so that the default service pro- 
file cache shown in Fig. 64 hits. Accordingly, the re- 
ceived packet Is decapsulated according to this 
sen^ice profile. Then, the service profile cache is 
again searched by using the home address of the 
mobile node 600 as a key. In this search, the service 
profile cache shown In Fig. 53 hits. The received 
packet is again decapsulated according to the serv- 
ice profile. The decapsulated packet is then deliv- 
ered to the mobile node 600. 

[01 92] After receiving the binding update message by 
the above described (3), the correspondent node CN 
700 transmits an encapsulated packet to the network 
after encapsulating the packet in which an ANYCAST 
address is set as a destination address, for itself. 
[0193] Rgs. 59 and 60 exemplify the sequence for 
canceling a registration to an ANYCAST sen^ice. Here, 
assume that the AAAH 100 includes an authentication 
sender, an authorization server, and an accounting serv- 
er. 

(1 ) The mobile node 600 transmits a registration re- 
quest message in which "timer=0" is set to the FA 
500 upon temilnation of a communication. 
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. (2) The FA 600 forwards the registration request 
message to the HA 200. 

(3) Upon receipt of the registration request mes- 
sage in which "tlmer=0" is set, the HA 200 transmits 

a binding update message in which "timer=0" is set s 
to the correspondent node CN 700 to which a serv- 
ice profile is distributed. 

(4) Upon receipt of the binding update message in 
which "timer:=0" is set, the correspondent node CN 
700 deletes the service profile cache of the mobile io 
node 600, and returns a binding acknowledge mes- 
sage to the HA 200 at the same time. 

(5) The HA 200 deletes the service profile cache of 
the mobile node 600, and retums a registration re- 
ply message to the FA 500 at the same time. i^ 

(6) The FA 500 transmits the registration reply mes- 
sage to the mobile node 600. Then, the FA 500 dis- 
connects an access network link, and transmits an 
accounting slop message to the accounting server 
of the AAAH 1 00 at the same time. 

(7) The accounting server stops the accounting 
process, and requests the authorization server to 
release the session. The authorization server re- 
quests the address proxy server 800 to delete the 
address information of the mobile node 600 from 
the service profile. 

(8) The authorization server requests the authenti- 
cation server of the AAAH 100 to release the ses- 
sion. * 

(9) The AAAH 1 00 requests the authentication serv- 30 
er of the AAAF 400 to release the session. 

(1 0) The AAAF 400 deletes the service profile, and 
retums a session release reply to the AAAH 100 at 
the sliririe time. 

(1 1 ) The AAAH 1 00 deletes the service profile, and 35 
retums the session release reply to the authoriza- 
tion server. 

(12) The authorization server returns the session 
release reply to the accounting server. 

(1 3) The accounting server returns accounting stop 
reply message to the FA 500. 

(14) The FA 500 deletes the service cache. 

[0194] According to the present invention, the func- 
tions for controlling services are centralized In an AAA, 45 
whereby the loads on an HA and an FA are reduced, 
and the maintenance (including a function addition and 
deletion) is facilitated. 

[0195] Additionally, according to the present inven- 
tion, a service profile which is referenced when a service so 
is provided to a plurality of mobile nodes that request 
the same service set is shared, so that it becomes easy 
to manage the service profile, and a search speed can 
be increased owing to the compression of search data. 
[0196] Furthenmore, according to the present inven- 55 
tion, a service-independent unit providing the funda- 
mental functions (including a routing process and the 
mobile IP) which are not dependent on a service, and 



an individual service unit using the service-Independent 
unit based on the information for providing each service 
are separated, thereby adding/changing a service with 
ease. 

[0197] Still further, according to the present invention, 
a particular terminal can be accurately specified on a 
network-wide scale In a service with which one virtual 
address is assigned to a plurality of terminals. 

Claims 

1 . A mobile communications service providing system 
in which location registration request infomnation is 
transmitted from a mobile node (600) to a home 
agent (200) via a foreign agent (500) and a server 
system (100, 400), and Infomnatlon In reply to the 
location registration request information is retumed 
from the home agent (200) to the mobile node (600) 
via the server system (100, 400) and the foreign 
agent (500), so that a location of the mobile node 
(600) is registered to the home agent (200) and the 
foreign agent (500), and a mobile communications 
service is provided based on the registration, 
wherein: 

the home agent (200) and the foreign agent 
(500) comprise a controlling unit determining a 
transfer destination of a packet; 
the server system (100, 400) comprises 

an extracting unit extracting a service pro- 
file corresponding to the mobile node (600) 
from a database (300) for managing a serv- 
ice profile which includes infonnation for 
providing a service requested by the mo- 
bile node (600), 

a service managing unit editing the service 
profile extracted by said extracting unit into 
a fonnat that Is available to said controlling 
unit, and 

a distributing unit distributing the service 
profile edited by said service managing unit 
to the home agent (200) and the foreign 
agent (500), and 

the home agent (200) and the foreign agent 
(500) provide a service by using said con- 
trolling unit according to the service profile 
distributed from the server system (1 00, 
400), 

2. The system according to claim 1 , wherein 

the server system (1 00, 400) does not distribute 
a service profile to the home agent (200) and 
the foreign agent (500),- if the mobile node (600) 
does not request a value-added service, and 
the home agent (200) and the foreign agent 



27 



BNSDCCID: <EP___1128832A2J_> 



53 



EP 1 128 632 A2 



54 



(500) provide a fundamental service according 
to information that the home agent (200) and 
the foreign agent (500) themselves generate. 

The system according to claim 1 , wherein: s 

an address range available forapredetermined 
service is specified beforehand; 
a service profile including information repre- 
senting the address range which is specified io 
beforehand is set in the home agent (200) and 
the foreign agent (500) as a condition for ex- 
tracting a correspondingpacketfrom among re- 
ceived packets; and 

the server system (100, 400) assigns an ad- i5 
dress within the address range to the mobile 
node (600) that requests the predetermined 
service. 

The system according to claim 1 , wherein: 20 

the server system (1 00, 400) comprises a home 
server device (1 00) which has a right to access 
the database (300) in order to extract the serv- 
ice profile for the mobile node (600), and a for- 25 
eign server device (400) which does not have 
such an access right; and 
the home server device (100) distributes the 
service profile to the home agent (200) and the . 
foreign server device (400). and the foreign 30 
server device (400) forwards the service profile 
to the foreign agent (500). 

The system according to claim 1 , wherein: 

35 

the server system (1 00, 400) comprises a home 
server device (1 00) which has a right to access 
the database (300) in order to extract the serv- 
ice profile for the mobile node (600), and a for- 
eign server device (400) which does not have 40 
such an access right; and 
the home server device (100) distributes the 
service profile to the foreign server device 
(400), and the foreign server device (400) for- 
wards the service profile to the home agent 45 
(200) and the foreign agent (500). 

The system according to claim 1 , wherein: 

the server system (1 00, 400) comprises a home so 
server device (1 00) which has a right to access 
the database (300) in order to extract the serv- 
ice profile for the mobile node (600), and a for- 
eign server device (400) which does not have 
such an access right; 55 
the mobile node (600) notifies the home agent 
(200) of location registration request informa- 
tion via a second foreign agent (500n) when 



moving from a communication area of aflrstfor- 
eign agent (500p) to a communication area of 
the second foreign agent (500n); 
the home agent (200) updates infomiation for 
routing a packet so that a packet addressed to 
the mobile node (600) is transferred to the sec- 
ond foreign agent (500n); and 
the foreign server device (400) distributes the 
service profile to the second foreign agent 
(500n). 

7. The system according to claim 1 , wherein: 

the server system (1 00, 400) comprises a home 
server device (1 00) which has a right to access 
the database (300) in order to extract the serv- 
ice profile for the mobile node (600), and first 
and second foreign server devices (400p, 
4C0n) which do not have such an access right; 
the mobile node (600) notifies the home agent 
(200) of location registration request informa- 
tion via a second foreign agent (500n), the sec- 
ond foreign server device (400n), and the home 
server device (100) when moving from a com- 
munication area of a first foreign agent (SQOp) 
managed by the first foreign server device 
(400p) to a connmunlcation area of the second 
foreign agent (SOOn) managed by the second 
foreign server device (400n); 
the home agent (200) updates information for 
routing a packet so that a packet addressed to 
the mobile node (600) is transferred to the sec- 
ond foreign agent (SOOn); and 
the home server device (100) distributes the 
service profile to the second foreign server de- 
vice (400n), which then forwards the service 
profile to the second foreign agent (SOOn). 

8. The system according to claim 1 . wherein: 

the server system (1 00, 400) comprises a home 
server device (1 00) which has a right to access 
the database (300) in order to extract a service 
profile for the mobile node (600), and first and 
second foreign server devices (400n, 40OP) 
which do not have such an access right; 
the mobile node (600) notifies the home agent 
(200) of location registration request informa- 
tion via a second foreign agent (SOOn), the sec- 
* ond foreign server device (400n), the home 
server device (1 00), and the first foreign server 
device (400p) when moving from a communi- 
cation area of a first foreign agent (600p) man- 
aged by the first foreign server device (400P) 
to a communication area of the second foreign 
agent (SOOn) managed by the second foreign 
server device (400n); 

the home agent (200) updates information for 
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routing a packet so that a packet addressed to 
the mobile node (600) is transferred to the sec- 
ond foreign agent (SOOn); and 
the home sen/er device (100) distributes the 
service profile to the second foreign server de- 
vice (400n), which then fonwards the service 
profile to the second foreign agent (SOOn), 

9. The system acconding to claim 1 , wherein: 

upon receipt of the packet addressed to the mo- 
bile node (600) from a con^espondent node 
(700), the home agent (200) distributes to the 
correspondent node (700) a service profile for 
extracting a packet in which the mobile node 
(600) is set as a destination; and 
the correspondent node (700) generates Infor- 
mation for transmitting to the foreign agent 
(500) a packet which is extracted according to 
the distributed service profile. 

10. The system according to claim 1 , wherein 

when providing a service for transferring to an 
arbitrary mobile node among a plurality of mobile 
nodes a packet with a virtual address assigned to 
the plurality of mobile nodes as a destination: 

an raddress proxy server (800) receiving the 
packet with the virtual address is arranged; and 
the server system (1 00, 400) distributes to said 
address proxy server (800) a service profile for 
extracting the packet with the virtual address is 
assigned and transfen-ing the extracted packet 
to the particular mobile node among the plural- 
ity of mobile nodes, and also distributes to a for- 
eign agent (500) a service profile for transfer- 
ring to the particular mobile node a packet ad- 
dressed to the foreign agent (500) which ac- 
commodates the particular mobile node. 

1 1 . A mobile communications service providing method 
with which location registration request infomriation 
is transmitted from a mobile node (600) to a home 
agent (200) via a foreign agent (500) and a server 
system (100, 400), and infomriation In reply to the 
location registration request infomnation is returned 
from the home agent (200) to the mobile node (600) 
via the server system (100, 400) and the foreign 
agent (500), so that a location of the mobile node 
(600) is registered to the home agent (200) and the 
foreign agent (500), and a mobile communications 
service is provided based on the registration, 
wherein: 

the home agent (200) and the foreign agent 
(500) comprise a controlling unit determining a 
transfer destination of a packet, the method com- 
prisng: 



extracting, by the server system (100, 400), a 
service profile con-esponding to the mobile 
node (600) from a database (300) for managing 
a sen/ice profile which Includes infonnatlon for 
providing a service requested by the mobile 
node (600); 

editing, by the server system (100,400), the ex- 
tracted service profile into a format that is avail- 
able to the controlling unit; and 
distributing the edited service profile from the 
server system (100, 400) to the home agent 
(200) and the foreign agent (500), and 
the home agent (200) and the foreign agent 
(500) provide a sen/ice by using the controlling 
unit according to the service profile distributed 
from the server system (1 00, 400). 

12. A mobile communications service providing method 
with which location registration request infonmation 
is transmitted from a mobile node (600) to a home 
agent (200) via a foreign agent (500) and a server 
system (100, 400), and information in reply to the 
location registration request informatwn is returned 
from the home agent (200) to the mobile node (600) 
via the server system (100, 400) and the foreign 
agent (500), so that a location of the mobile node 
(600) Is registered to the home agent (200) and the 
foreign agent (500). and a mobile communications 
service is provided based on the registration, the 
method conrprlsing: 

extracting, by the server system (100, 400). a 
service profile corresponding to the mobile 
node (600) from a database (300) for managing 
a service profile which includes information for 
providing a service requested by the mobile 
node (600); 

editing, by the sender system (1 00, 400), the ex- 
tracted service profile Into a format that Is not 
dependent on a service type; and 
distributing the edited service profile from the 
server system (100, 400) to the home agent 
(200) and the foreign agent (500), and 
the home agent (200) and the foreign agent 
(500) provide a service according to the service 
profile distributed from the server system (1 00, 
400). 



13. A mobile communications service providing method 
50 used in a system which comprises a database (300) 
for managing a sen^tee profile which includes infor- 
mation for providing a servtee requested by a mo- 
bile node (600), a plurality of agents (200, 500) 
which can respectively accommodate the mobile 
55 node (600), and a server (100) which extracts a 
service profile for the mobile node and distributes 
the extracted service profile to the agents which ac- 
commodate the mobile node (600), wherein: 
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the plurality of agente (200, 500) respectively 
comprise a controlling unit determining a trans- 
fer destination of a packet; 
the server (100) edits the service profile ex- 
tracted from the database (300) into a fonnat s 
that is available to the controlling unit arranged 
in the agents, and distributes the edited service 
profile to the agents which accommodate the 
mobile node (600); and 

the agents which accommodate the mobile io 
node (600) provide a service by using the con- 
trolling unit according to the service profile ed- 
ited by the server (1 00). 

14. A server system (100) used in a mobile communi- is 
cations service providing system in which location 
registration request fnformation is transmitted from 
a mobile node (600) to a home agent (200) via a 
foreign agent (500) and a server system (1 00), and 
information in reply to the location registration re- so 
quest information is returned from the home agent 
(200) to the mobile node (600) via the sever system 
(1 00) and the foreign agent (500) , so that a location 
of the mobile node (600) is registered to the home 
agent (200) and the foreign agent (500), and a mo- 25 
bile communications service is provided based on 
the registration, said server system (100) compris- 
ing: 

an extracting unit extracting a service profile for so 
the mobile node (600) from a database (300) 
for managing a service profile which includes 
information for providing a service requested by 
a mobile node (600); 

a servicemanaging unit editing the sen/ice pro- 35 
file extracted by said extracting unit into a for- 
mat that Is available to a controlling unit for de- 
termining a transfer destination of a packet by 
the home agent (200) and the foreign agent 
(500); and 40 
a distributing unit distributing the edited sen^ice 
profile to the home agent (200) and the foreign 
agent (500) so that the home agent (200) and 
the foreign agent (500) provide a service by us- 
ing the controiling unit according to the service 
profile edited by said service managing unit. 

15- An agent device (200, 500) as a home agent (200) 
or a foreign agent (500) for use in a mobile commu- 
nications service providing system in which location so 
registration request information is transmitted from 
a mobile node (600) to the home agent (200) via the 
foreign agent (500) and a server system (1 00, 400), 
and information in reply to the location registration 
request infonnation is returned from the home 55 
agent (200) to the mobile node (600) via the server 
system (100, 400) and the foreign agent (500), so 
that a location of the mobile node (600) is registered 



to the home agent (200) and the foreign agent 
(500), and a mobile communications service Is pro- 
vided based on the registration, said agent (200, 
500) comprising: 

a sen^ice-independent unit (204) determining a 
processing method for a received packet ac- 
cording to header infomnation of the received 
packet; 

an individual service controlling unit (203) using 
said service-independent unit (204) according 
to a service profile edited into a fonnat that is 
available to said service-independent unit 
(204) by the server system (100, 400); and 
a packet controlling unit (201) processing a 
packet according to a processing result of use 
of said service-Independent unit (204). 
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